Re: [patch 6/12] hold atomic kmaps across generic_file_read

[Andrew Morton <akpm@zip.com.au>]

Linus Torvalds wrote:
> 
> ...
> Basically, it _used_ to be that each page got woken up one at a time as
> they became ready after IO. With the new scheme, they all get woken up
> together in "mpage_end_io_read()" (or write, but since people usually
> don't wait for writes..).
> 
> At least that is how I read the code. Andrew?

Yes.  The basic unit of IO in there is a 64k BIO.  So once readahead
is cruising, pages come unlocked in 16-page batches.  In 2.4 they'll
come unlocked one at a time against a device such as a floppy drive.

But with default settings the readahead code lays one to two of these
BIOs out ahead of the read point, so the application never stumbles across
a locked page unless it's outpacing the device.

At least that's the theory, and the testing I did yesterday
was succesful.

So I'd appreciate it if Simon could invetigate a little further
with the test app I posted.  Something is up, and it may not
be just an NFS thing.  But note that nfs_readpage will go
synchronous if rsize is less than PAGE_CACHE_SIZE, so it has
to be set up right.