Messages in this thread | | | Date | Mon, 1 Nov 2004 23:34:19 +0100 | From | Andrea Arcangeli <> | Subject | Re: PG_zero |
| |
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. - 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/
| |