[lkml]   [2001]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-2.4.10-pre5
On September 11, 2001 02:20 am, Linus Torvalds wrote:
> On Tue, 11 Sep 2001, Daniel Phillips wrote:
> > On September 11, 2001 12:15 am, Linus Torvalds wrote:
> > > However, physical read-ahead really isn't the answer here. I bet you could
> > > cut your time down with it, agreed. But you'd hurt a lot of other loads,
> > > and it really depends on nice layout on disk. Plus you wouldn't even know
> > > where to put the data you read-ahead: you only have the physical address,
> > > not the logical address, and the page-cache is purely logically indexed..
> >
> > You leave it in the buffer cache and the page cache checks for it there
> > before deciding it has to hit the disk.
> Umm..
> Ehh.. So now you have two cases:
> - you hit in the cache, in which case you've done an extra allocation,
> and will have to do an extra memcpy.
> - you don't hit in the cache, in which case you did IO that was
> completely useless and just made the system slower.

If the read comes from block_read then the data goes into the page cache. If
it comes from getblk (because of physical readahead or "dd xxx >null") the
data goes into the buffer cache and may later be moved to the page cache,
once we know what the logical mapping is.

> Considering that the extra allocation and memcpy is likely to seriously
> degrade performance on any high-end hardware if it happens any noticeable
> percentage of the time, I don't see how your suggest can _ever_ be a win.
> The only time you avoid the memcpy is when you wasted the IO completely.

We don't have any extra allocation in the cases we're already handling now,
it works exactly the same. The only overhead is an extra hash probe on cache

> So please explain to me how you think this is all a good idea? Or explain
> why you think the memcpy is not going to be noticeable in disk throughput
> for normal loads?

When we're forced to do a memcpy it's for a case where we're saving a read or
a seek. Even then, the memcpy can be optimized away in the common case that
the blocksize matches page_size. Sometimes, even when the blocksize doesn't
match this optimization would be possible. But the memcpy optimization isn't
important, the goal is to save reads and seeks by combining reads and reading
blocks in physical order as opposed to file order.

An observation: logical readahead can *never* read a block before it knows
what the physical mapping is, whereas physical readahead can.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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