Re: [PATCH] GFP_THISNODE for the slab allocator

[Paul Jackson <pj@sgi.com>]

Christoph wrote:
> What you are doing is using nodes to partition memory into small chunks
> that are then collected in a cpuset. That is not the way how nodes
> or cpusets were designed to work.

Agreed, and a tad frustrating.

However, in Andrew's favor, he has discovered that despite our best
design efforts, this node/cpuset/... stuff actually does work "out
of the box" when (ab)used in this strange fashion.

Except for one performance glitch, where a loop in the routine
get_page_from_freelist() loops too many times, he's got the makings
of memory containers 'for free.'

If he could just get the performance of that loop in this fake NUMA
setup from linear in the number of filled up fake nodes, back to a
small constant, he'd be good to go with this new mechanism.

The only useful part of this debate is how many words of cached data
per something (cpu, cpuset, node, zonelist, task, ...)  it will take
to get this loop cost back to a small constant, even when presented
with such a sorry excuse for a zonelist.

Andrew started at one word; I started at MAX_NUMNODES words.  I've got
him up to two words; he has me down to three words.

We're converging fast.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>