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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:26 EST