[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Getting FS access events

On Mon, 14 May 2001, Richard Gooch wrote:
> Is there some fundamental reason why a buffer cache can't ever be
> fast?


Or rather, there is a fundamental reason why we must NEVER EVER look at
the buffer cache: it is not coherent with the page cache.

And keeping it coherent would be _extremely_ expensive. How do we
know? Because we used to do that. Remember the small mindcraft
benchmark? Yup. Double copies all over the place, double lookups, double

You could think: "oh, we only need to look up the buffer cache when we
create a new page cache mapping, so..".

You'd be wrong. We'd need to go the other way too: every time we create a
new buffer cache entry, we'd need to make sure that it isn't mapped
somewhere in the page cache (impossible), or otherwise we'd do the wrong
thing sometimes (ie we might have two dirty copies, and we wouldn't know
_which_ one is valid etc).

Aliasing is bad. Don't do it.

Really. Give it up. Your silly "make bootup faster" is not going to happen
this way. You're trying to break some rather fundamental data structures,
all for the unusual case of booting up. There are other ways to boot up
quickly: look into pre-filling your memory image (aka "resume from disk"),
which I will _guarantee_ you is a lot faster than anything else you can
come up with, and which doesn't have the downsides that your approach has.

You know, the mark of intelligence is realizing when you're making the
same mistake over and over and over again, and not hitting your head in
the wall five hundred times before you understand that it's not a clever
thing to do.

Please show some intelligence.


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 12:53    [W:0.189 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site