Messages in this thread | | | Date | Wed, 25 Oct 2000 11:56:31 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: PATCH: killing read_ahead[] |
| |
Alexander Viro wrote: > > On Wed, 25 Oct 2000, Linus Torvalds wrote: > > > > > > > On Wed, 25 Oct 2000, Rik van Riel wrote: > > > > > > OTOH, block-dev readahead makes sense for filesystems where > > > the packing locality is close to the access pattern BUT NOT > > > close to anything the page cache would recognise as being > > > close. > > > > I dunno. The main reason I'd like to get the block devices into the page > > cache is that right now there is no way to mmap them - something that can > > potentially be _very_ useful, regardless of readahead. > > > > And quite frankly, the generic file readahead has been pounded upon and > > tested a lot more than the block device read-ahead ever was. I bet it > > performs better if for no other reason. > > Umm... OK, I think that I can do it. Prerequisit: two new fields in > address_space that make sense by themselves: > (i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT > (i_size & ~PAGE_CACHE_MASK) ? : PAGE_CACHE_SIZE > > Can we add it now? I mean the following: we have _very_ few places where > i_size is being changed. We could easily calculate these two expressions > at such points and put them into ->i_mapping. That kills quite a few long > long shifts (Good Thing, IMO) in places where we are using these values. > > _If_ we can have it on that stage - devices in pagecache are trivial. > Frankly, I think that caching them makes sense regardless of > device-related stuff. > > I can do the proof-of-concept patch (below 10Kb, ext2 + generic code, with > the need to repeat the fs-specific parts for other filesystems) in an > hour. Clearance?
Al,
Sounds like we are going to change it and break the fs's again. Let me know where the patch ends up so I can merge these changes and test them.
:-)
Jeff
> > Notice that said fields do _not_ replace i_size. They mirror it and allow > to > * avoid costly recaclulation > * have generic_file_read / filemap_nopage free from references to > inode->i_size, thus making them more usable for devices. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |