[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: killing read_ahead[]
On Tue, Oct 24, 2000 at 12:46:36PM -0700, Linus Torvalds wrote:
> Actually, the _real_ answer is to make fs/block_dev.c use the page cache
> instead - and generic_file_read() does read-ahead that actually improves
> performance, unlike the silly contortions that the direct block-dev
> read-ahead tries to do.

If we had a paper about the page cache this would be easy.

In the beginning page cache was just previously mmaped pages,
that are clean and ready to be mapped again.

Today we have them either dirty or clean, mapped or not(?), with and
without buffers, in highmem(?) or lowmem and everybody and its
children is using it for everything.

We need a clear definition about (concurrent) states of page
cached pages, valid transitions (and locks/sema4s to take for
them), assumptions, guarantees etc.

The only thing I see guaranteed, that every big thing to be
cached should live there and is page aligned and page sized.

I'm trying hard to understand a concept in the page cache and to
get it's limits and guarantees, but still find it hard to get

Time for specs, I would say ;-)

I could help to explain and formulate, if someone could only cut
the edges of how it works and what it will be.

Thanks & Regards

Ingo Oeser
Feel the power of the penguin - run linux@your.pc
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.075 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site