Re: Excessive memory trapped in pageset lists

[Dave Hansen <haveblue@us.ibm.com>]

On Thu, 2005-04-07 at 16:11 -0500, Jack Steiner wrote:
>    28 pages/node/cpu * 512 cpus * 256nodes * 16384 bytes/page = 60GB  (Yikes!!!)
...
> I have a couple of ideas for fixing this but it looks like Christoph is
> actively making changes in this area. Christoph do you want to address
> this issue or should I wait for your patch to stabilize?

What about only keeping the page lists populated for cpus which can
locally allocate from the zone?

	cpu_to_node(cpu) == page_nid(pfn_to_page(zone->zone_start_pfn)) 

There certainly aren't a lot of cases where frequent, persistent
single-page allocations are occurring off-node, unless a node is empty.
If you go to an off-node 'struct zone', you're probably bouncing so many
cachelines that you don't get any benefit from per-cpu-pages anyway.

Maybe there could be a per-cpu-pages miss rate that's required to occur
before the lists are even populated.  That would probably account better
for cases where nodes are disproportionately populated with memory.
This, along with the occasional flushing of the pages back into the
general allocator if the miss rate isn't satisfied should give some good
self-tuning behavior.

-- Dave

--
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:"aart@kvack.org"> aart@kvack.org </a>