[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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:

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
* 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.059 / U:1.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site