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