Messages in this thread | | | Date | Wed, 25 Oct 2000 00:30:49 +0200 | From | Ingo Oeser <> | Subject | Re: 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 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |