Messages in this thread | | | Date | Sun, 11 Aug 2002 20:28:12 -0700 | From | Andrew Morton <> | Subject | Re: [patch 6/12] hold atomic kmaps across generic_file_read |
| |
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/
| |