Re: [PATCH 22/33] readahead: initial method

[Wu Fengguang <wfg@mail.ustc.edu.cn>]

On Thu, May 25, 2006 at 03:34:30PM +1000, Nick Piggin wrote:
> BTW. while your patchset might be nicely broken down, I think your
> naming and descriptions are letting it down a little bit.

:) Maybe more practices will help.

> Wu Fengguang wrote:
> 
> >Aggressive readahead policy for read on start-of-file.
> >
> >Instead of selecting a conservative readahead size,
> >it tries to do large readahead in the first place.
> >
> >However we have to watch on two cases:
> >	- do not ruin the hit rate for file-head-checkers
> >	- do not lead to thrashing for memory tight systems
> >
> >
> 
> How does it handle
>             -  don't needlessly readahead too much if the file is in cache

It is prevented by the calling scheme.

The adaptive readahead logic will only be called on
        - read a non-cached page
                So readahead will be started/stopped on demand.
        - read a PG_readahead marked page
                Since the PG_readahead mark will only be set on fresh
                new pages in __do_page_cache_readahead(), readahead
                will automatically cease on cache hit.

> 
> Would the current readahead mechanism benefit from more aggressive 
> start-of-file
> readahead?

It will have the same benefits(and drawbacks).

[QUOTE FROM ANOTHER MAIL]
> can we try to incrementally improve the current logic as well as work
> towards merging your readahead rewrite?

The current readahead is left untouched on purpose.

If I understand it right, its simplicity is a great virtue.  And it is
hard to improve it without loosing this virtue, or avoid disturbing
old users.

Then the new framework provides a ideal testbed for fancy new things.
We can do experimental things without calling for complaints(before it
is stabilized after one year). And then we might port some proved
features to the current logic.

Wu