Re: PG_zero

[Andrea Arcangeli <andrea@novell.com>]

On Mon, Nov 01, 2004 at 10:03:56AM -0800, Martin J. Bligh wrote:
> [..] it was to stop cold
> allocations from eating into hot pages [..]

exactly, and I believe that hurts. bouncing on the global lock is going to
hurt more than preserving an hot page (at least on a 512-way). Plus the
cold page may very soon become hot too.

Plus you should at least allow an hot allocation to eat into the cold
pages (which didn't happen IIRC).

I simply believe using the lru ordering is a more efficient way to
implement hot/cold behaviour and it will save some minor ram too (with
big lists the reservation might even confuse the oom conditions, if the
allocation is hot, but the VM frees in the cold "stopped" list). I know
the cold list was a lot smaller so this is probably only a theoretical
issue.

> Yeah, we got bugger-all benefit out of it. The only think it might do
> is lower the latency on inital load-spikes, but basically you end up
> paying the cache fetch cost twice. But ... numbers rule - if you can come
> up with something that helps a real macro benchmark, I'll eat my non-existant
> hat ;-)

I've no idea if it will help... I only knows it helps the micro ;), but I
don't measure any slowdown.

Note that my PG_zero will boost 200% the micro benchmark even without
the idle zeroing enabled, if a big app quits all ptes will go in PG_zero
quicklist and the next 2M allocation of anonymous memory won't require
clearing. That has no downside at all. That's not something that can be
achieved with slab, plus slab wastes ram as well and it has more
overhead than PG_zero.