Messages in this thread | | | Date | Mon, 01 Nov 2004 15:47:23 -0800 | From | "Martin J. Bligh" <> | Subject | Re: PG_zero |
| |
Apologies to akpm if you're not getting this directly ... OSDL is spitting my email back as spam.
> 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.
? which global lock are we talking about now? the buddy allocator? mmm, yes, might well do. OTOH, with hot/cold pages the lock should hardly be contended at all (512-ways scare me, yes ... but they're broken in lots of other ways ;-) ... do we have lockmeter data from one?
> Plus you should at least allow an hot allocation to eat into the cold > pages (which didn't happen IIRC).
I think the hotlist was set to refill from the cold list before it refilled from the buddy ... or it was at one point.
> 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.
well, it'd only save RAM in theory on SMP systems where the load was very unevenly distributed across CPUs ... it's out of the reserved pool.
>> 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.
Let's see what it does on the macro-benchmarks ;-)
M.
- 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/
| |