On Mon, 11 Jun 2007, Eric Sesterhenn / Snakebyte wrote: > > +unlikely | 40969931| 6228144 __slab_free()@:mm/[EMAIL PROTECTED] > +unlikely | 47198075| 0 __slab_free()@:mm/[EMAIL PROTECTED] > -likely | 0| 47198075 slab_free()@:mm/[EMAIL PROTECTED] > +unlikely | 47280864| 0 __slab_alloc()@:mm/[EMAIL PROTECTED] > +unlikely | 26857| 0 new_slab()@:mm/[EMAIL PROTECTED] > +unlikely | 47280864| 0 slab_alloc()@:mm/[EMAIL PROTECTED] > > 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 "slub_debug". 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
