Re: [PATCH] SLUB use cmpxchg_local

Mathieu Desnoyers
2007-08-21T23:12:44Z

* Christoph Lameter (clameter@sgi.com) wrote:
> 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.
>

I seem to get a clear performance improvement in the kmalloc fast path.

> > It applies on top of the
> > "SLUB Use cmpxchg() everywhere" patch.
>
> Which one is that?
>

This one:

SLUB Use cmpxchg() everywhere.

It applies to "SLUB: Single atomic instruction alloc/free using
cmpxchg".

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: slab/mm/slub.c
===================================================================
--- slab.orig/mm/slub.c 2007-08-20 18:42:16.000000000 -0400
+++ slab/mm/slub.c 2007-08-20 18:42:28.000000000 -0400
@@ -1682,7 +1682,7 @@ redo:

object[c->offset] = freelist;

- if (unlikely(cmpxchg_local(&c->freelist, freelist, object) != freelist))
+ if (unlikely(cmpxchg(&c->freelist, freelist, object) != freelist))
goto redo;
return;
slow:

> > | 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.
>

Yes. slab_free in these tests falls mostly into __slab_free() slow path
(I instrumented the number of slow and fast path to get this). The small
performance hit (~10 cycles) can be explained by the added
preempt_disable()/preempt_enable().

> The kmalloc numbers look encouraging. I will check to see if I can
> reproduce it once I sort out the patches.

Ok.