Re: [RFC] memory page_alloc zonelist caching speedup

Paul Jackson
2006-10-10T04:51:25Z

pj wrote:
> I guess this means we add a counter to the zonelist_cache struct.
> Increment it each time we try to allocate a page from that zonelist.
> Trigger a zap (cache expiration) if the counter hits 1000, and clear
> the counter when we do the zap.

No, dang it. Not count allocs. Count frees.

My zonelist caching adapts immediately to another node being filled
up due to allocs, by turning on another bit in the fullzones bitmask.

But it doesn't adapt immediately to memory coming free.

An application could say free up a big chunk of memory on its
local node - perhaps by dropping the last reference to an anonymous
memory region.

It would then reasonably expect that new allocations would come
from the local node - right then - not starting some later time
up to one second in the future.

I think I'd need a per-node counter of frees, incremented on each free,
and checked by the zonelist caching to see if it should consider that
node no longer full.

-However- that forces a per-node reference in the zonelist caching
code as part of the scan for a free page. That is exactly what we
were trying to avoid!

No. Not count frees either. Don't count anything.

I do not see how to count anything related to allocs or frees and
then use that counter to throttle the zonelist caching, without
re-introducing the lousy cache line footprint that I just got done
shrinking.

That's why I like time based throttles. They are cheap. Dirt cheap.
Infinitely scalable. And stupid as a pet rock ;).

P.S. I don't think that the above application, expecting instant reuse
of node local memory, even though it had just been pushing allocations
off-node, is a real problem. Anyone care to claim otherwise?