Stephen Lord wrote:

On Thu, 2002-07-25 at 14:40, Andrew Morton wrote:

quoted

Rik van Riel wrote:

quoted

On Thu, 25 Jul 2002, Christoph Hellwig wrote:

quoted

This function (start_aggressive_readahead()) checks whether all zones
of the given gfp mask have lots of free pages.

Seems a bit silly since ideally we wouldn't reclaim cache memory
until we're low on physical memory.

Yes, I would question its worth also.


What it boils down to is:  which pages are we, in the immediate future,
more likely to use?  Pages which are at the tail of the inactive list,
or pages which are in the file's readahead window?

I'd say the latter, so readahead should just go and do reclaim.

The interesting thing is that tuning metadata readahead using
this function does indeed improve performance under heavy memory
load. It seems we end up pushing more useful things out of
memory than the metadata we read in.

I'm surprised.  Could be that even when there is no memory
pressure, you're simply reading stuff which you're never using?

Ah.  Could be that the improvements which you saw are nothing
to do with leaving memory free, and everything to do with the
extreme latency which occurs in page reclaim when the system
is under load.  (I'm whining again).

Andrew, you talked about
a GFP flag which would mean only return memory if there was
some available which was already free and clean.

Yes, you can do that now.  Just use

	GFP_ATOMIC & ~__GFP_HIGH

and the allocation will fail if it could not be satisfied
from a zone which has (free_pages > zone->pages_min).

Which will dip further into the page reserves than the
start_aggressive_readahead() approach would have, but it'll
certainly get around the page reclaim latency.

(You'll need to set PF_NOWARN around the call, else the
page allocator will spam you to death.  Sorry)

-
--
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-mm.org/