[380] in linux-scsi channel archive
Re: Reading more than buffersize
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sun Jul 16 02:03:50 1995
Date: Sat, 15 Jul 95 23:01 EDT
From: eric@aib.com (Eric Youngdale)
To: Drew Eckhardt <drew@poohsticks.org>
CC: mucci@cs.utk.edu, linux-scsi@vger.rutgers.edu
>One difficult bit is maintaining synchronicity with the buffer
>cache in a way that's compatable with performance. If you do a single
>direct read/write, it would probably be optimal to just set your pages
>to COW and give them a context in the buffer cache as wll.
Hmm, I was thinking in terms of only a character device. The
normal block devices already effectively do it with 0 copies (provided
that bounce buffers are not required), since we perform DMA directly into
the buffer cache. The problem is that if the user wants to read a file,
we have one copy out of the buffer cache into the user's buffer. If the
user mmaps the file, this would eliminate the copy, but the I/O requests
would probably only be done one page at a time as page faults occur.
This was one optimization to the memory manager that I was thinking of
trying at one point (a read-ahead built into the page-fault handling - I
think someone may have even implemented it).
Are you thinking of a way of reading into the buffer cache
without copying into the user's buffer that would be compatible with
mmap?
>Not necessarily. On some reads ("some" defined as being with host adapters
>that support a limited (for practical purposes) number of scatter/gather
>segements it will be cheaper to allocate contiguous pages, map those in (with
>no zero-fill), copy the untouched bits of the two end pages into that
>buffer, and discard the old pages.
Interesting idea. It would work of course, but it might be a bit
complicated.
One of the first things you might need to do is inspect the kmalloc
code with the GFP_DMA bit set - when it was first implemented it was fairly
stupid and had pathological behavior in tight memory situations (i.e.
it would keep grabbing pages from the free list until it found something
below the DMA threshold, and then it put all of the unsuitable ones back
on the free list - this can lead to lots of swapping/thrashing). It may
have been improved recently - I have not checked.
-Eric
