Re: Avoid allocating during interleave from almost full nodes

[Andrew Morton <akpm@osdl.org>]

On Fri, 3 Nov 2006 14:10:01 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> > 
> > Wall time is a bogus concept in the VM.  Can we please stop relying upon it?
> 
> We use the same 2 second pulse to drain slab caches, and the page 
> allocators per cpu caches. The slab draining has been around forever.

And it doesn't make sense there either.

Well.  There are situations where it makes a _bit_ of sense: in those
places where we are trying to determine whether a piece of memory is still
in the CPU's cache.  If we assume that the CPU is evicting cachelines at a
constant lines/sec rate then yes, using walltime has some correlation with
reality.

But in this application which you are proposing, any correlation with
elapsed walltime is very slight.  It's just the wrong baseline to use. 
What is the *sense* in it?

> > > not matter though since we always can fall back to operating without
> > > full_interleave_nodes. As a result of the racyness we may uselessly
> > > skip a node or retest a node.
> > 
> > This design relies upon nodes having certain amounts of free memory.  This
> > concept is bogus.  Because it treats clean pagecache which hasn't been used
> > since last Saturday as "in use".  It is not in use.
> 
> It relies on free pages, not on in use pages.

Yes.  And it is wrong to do so.  Because a node may well have no "free"
pages but plenty of completely stale ones which should be reclaimed.

This patch is very specific to the one particular usage scenario which your
users happen to deploy but is quite ineffective for other (and quite valid)
usage scenarios.

> The attempt is to bypass 
> expensive reclaim as long as we can find free memory on other nodes.

Reclaim isn't expensive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/