Messages in this thread |  | | Date | Wed, 25 Oct 2000 13:53:34 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: PATCH: killing read_ahead[] |
| |
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?
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/
|  |