Re: PATCH: killing read_ahead[]

Re: PATCH: killing read_ahead[]

[Ingo Oeser]

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/

Re: PATCH: killing read_ahead[]

[Jeff V. Merkey]

On Wed, Oct 25, 2000 at 12:30:49AM +0200, Ingo Oeser wrote:
> 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
> -

I hope we are not doing something stupid here, like breaking the 
f*!%cking page cache again.  I've finaly got all the bugs out of 
NWFS on 2.4.0-test9, and have waded through the breakage of the 
past two testX releases of 2.4.   

Why do we need to disable read ahead on the page cache anyway?

:-)

Jeff



> 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/
--
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/