Re: profiling likely/unlikely in slub.c

From: Christoph Lameter
Date: Mon Jun 11 2007 - 15:07:49 EST

On Mon, 11 Jun 2007, Eric Sesterhenn / Snakebyte wrote:

> +unlikely | 40969931| 6228144 __slab_free()@:mm/slub.c@1606
> +unlikely | 47198075| 0 __slab_free()@:mm/slub.c@1599
> -likely | 0| 47198075 slab_free()@:mm/slub.c@1660
> +unlikely | 47280864| 0 __slab_alloc()@:mm/slub.c@1475
> +unlikely | 26857| 0 new_slab()@:mm/slub.c@1107
> +unlikely | 47280864| 0 slab_alloc()@:mm/slub.c@1557
> three of the unlikely cases are caused by "if (unlikely(SlabDebug(page)))"
> if SLUB_DEBUG is turned off, it really is unlikely, since SlabDebug()
> always returns 0, if SLUB_DEBUG is turned on it is likely (not sure if there are
> cases where it can return 0) therefore it makes sense to change this
> to likely for the SLUB_DEBUG case.
> The following patch changes the SlabDebug() functions to defines, so gcc
> can easily optimize the if away entirely and changes the unlikely() to a
> likely().
> Remaining problem is, that if likely/unlikely profiling is turned on,
> gcc does not optimize away a likely(0), and they still show up in the
> stats... guess heisenbug is involved in this :-)

There is a fundamental misunderstanding here to think that SLUB_DEBUG
would enable debugging. Not true. Debugging is enabled by booting with

It is true that SlabDebug() is always false if !CONFIG_SLUB_DEBUG. That is
only the case for embedded systems that want to conserve memory.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at