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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:16 EST