From: Eric Sesterhenn / Snakebyte <snakebyte@gmx.de>
To: linux-kernel@vger.kernel.org
Cc: clameter@sgi.com
Subject: profiling likely/unlikely in slub.c
Date: Mon, 11 Jun 2007 20:56:08 +0200 [thread overview]
Message-ID: <20070611185608.GB4592@alice> (raw)
hi,
when taking a look at /proc/likely_prof i noticed the following
+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 :-)
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
--- linux/mm/slub.c.orig 2007-06-11 09:04:15.000000000 +0000
+++ linux/mm/slub.c 2007-06-11 17:11:36.000000000 +0000
@@ -101,12 +101,6 @@
#define FROZEN (1 << PG_active)
-#ifdef CONFIG_SLUB_DEBUG
-#define SLABDEBUG (1 << PG_error)
-#else
-#define SLABDEBUG 0
-#endif
-
static inline int SlabFrozen(struct page *page)
{
return page->flags & FROZEN;
@@ -122,6 +116,9 @@ static inline void ClearSlabFrozen(struc
page->flags &= ~FROZEN;
}
+#ifdef CONFIG_SLUB_DEBUG
+
+#define SLABDEBUG (1 << PG_error)
static inline int SlabDebug(struct page *page)
{
return page->flags & SLABDEBUG;
@@ -136,6 +133,13 @@ static inline void ClearSlabDebug(struct
{
page->flags &= ~SLABDEBUG;
}
+#else
+
+#define SlabDebug(x) 0
+#define SetSlabDebug(x)
+#define ClearSlabDebug(x)
+
+#endif
/*
* Issues still to be resolved:
@@ -1129,7 +1133,7 @@ static void __free_slab(struct kmem_cach
{
int pages = 1 << s->order;
- if (unlikely(SlabDebug(page))) {
+ if (likely(SlabDebug(page))) {
void *p;
slab_pad_check(s, page);
@@ -1472,7 +1476,7 @@ load_freelist:
object = page->freelist;
if (unlikely(!object))
goto another_slab;
- if (unlikely(SlabDebug(page)))
+ if (likely(SlabDebug(page)))
goto debug;
object = page->freelist;
@@ -1596,7 +1600,7 @@ static void __slab_free(struct kmem_cach
slab_lock(page);
- if (unlikely(SlabDebug(page)))
+ if (likely(SlabDebug(page)))
goto debug;
checks_ok:
prior = object[page->offset] = page->freelist;
next reply other threads:[~2007-06-11 18:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 18:56 Eric Sesterhenn / Snakebyte [this message]
2007-06-11 19:07 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070611185608.GB4592@alice \
--to=snakebyte@gmx.de \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®