[lkml]   [2004]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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 ;-)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:07    [W:0.104 / U:214.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site