[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0708211404290.3082@schroedinger.engr.sgi.com>
Date: Tue, 21 Aug 2007 14:08:37 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
mingo@...hat.com
Subject: Re: [PATCH] SLUB use cmpxchg_local
On Tue, 21 Aug 2007, Mathieu Desnoyers wrote:
> - Fixed an erroneous test in slab_free() (logic was flipped from the
> original code when testing for slow path. It explains the wrong
> numbers you have with big free).
If you look at the numbers that I posted earlier then you will see that
even the measurements without free were not up to par.
> It applies on top of the
> "SLUB Use cmpxchg() everywhere" patch.
Which one is that?
> | slab.git HEAD slub (min-max) | cmpxchg_local slub
> kmalloc(8) | 190 - 201 | 83
> kfree(8) | 351 - 351 | 363
> kmalloc(64) | 224 - 245 | 115
> kfree(64) | 389 - 394 | 397
> kmalloc(16384)| 713 - 741 | 724
> kfree(16384) | 843 - 856 | 843
>
> Therefore, there seems to be a repeatable gain on the kmalloc fast path
> (more than twice faster). No significant performance hit for the kfree
> case, but no gain neither, same for large kmalloc, as expected.
There is a consistent loss on slab_free it seems. The 16k numbers are
irrelevant since we do not use slab_alloc/slab_free due to the direct pass
through patch but call the page allocator directly. That also explains
that there is no loss there.
The kmalloc numbers look encouraging. I will check to see if I can
reproduce it once I sort out the patches.
-
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