Re: PATCH: killing read_ahead[]

[Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>]

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
them.

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
<esc>:x
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/