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

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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [from the cache]
©2003-2011 Jasper Spaans