[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46935AE5.7050205@yahoo.com.au>
Date: Tue, 10 Jul 2007 20:09:41 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Pekka Enberg <penberg@...helsinki.fi>
CC: Christoph Lameter <clameter@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, suresh.b.siddha@...el.com,
corey.d.gough@...el.com, Matt Mackall <mpm@...enic.com>,
Denis Vlasenko <vda.linux@...glemail.com>,
Erik Andersen <andersen@...epoet.org>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23
Pekka Enberg wrote:
> Hi Nick,
>
> Pekka J Enberg wrote:
>
>> > That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
>> > debugging is disabled.
>
>
> On 7/10/07, Nick Piggin <nickpiggin@...oo.com.au> wrote:
>
>> Interesting. What kernel version are you using?
>
>
> Linus' git head from yesterday so the results are likely to be
> sensitive to workload and mine doesn't represent real embedded use.
Hi Pekka,
There is one thing that the SLOB patches in -mm do besides result in
slightly better packing and memory efficiency (which might be unlikely
to explain the difference you are seeing), and that is that they do
away with the delayed freeing of unused SLOB pages back to the page
allocator.
In git head, these pages are freed via a timer so they can take a
while to make their way back to the buddy allocator so they don't
register as free memory as such.
Anyway, I would be very interested to see any situation where the
SLOB in -mm uses more memory than SLUB, even on test configs like
yours.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists