[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703090907330.7315@schroedinger.engr.sgi.com>
Date: Fri, 9 Mar 2007 09:21:00 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Mel Gorman <mel@....ul.ie>
cc: akpm@...l.org, Marcelo Tosatti <marcelo@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
mpm@...enic.com, Manfred Spraul <manfred@...orfullife.com>
Subject: Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
On Fri, 9 Mar 2007, Mel Gorman wrote:
> The results without slub_debug were not good except for IA64. x86_64 and ppc64
> both blew up for a variety of reasons. The IA64 results were
Yuck that is the dst issue that Adrian is also looking at. Likely an issue
with slab merging and RCU frees.
> KernBench Comparison
> --------------------
> 2.6.21-rc2-mm2-clean 2.6.21-rc2-mm2-slub
> %diff
> User CPU time 1084.64 1032.93 4.77%
> System CPU time 73.38 63.14 13.95%
> Total CPU time 1158.02 1096.07 5.35%
> Elapsed time 307.00 285.62 6.96%
Wow! The first indication that we are on the right track with this.
> AIM9 Comparison
> 2 page_test 2097119.26 3398259.27 1301140.01 62.04% System Allocations & Pages/second
Wow! Must have all stayed within slab boundaries.
> 8 link_test 64776.04 7488.13 -57287.91 -88.44% Link/Unlink Pairs/second
Crap. Maybe we straddled a slab boundary here?
-
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