From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
"Weathers,
Norman R."
<Norman.R.Weathers-496aOtIFJR1B+Kdf37RAV9BPR1lH4CV8@public.gmane.org>
Subject: Re: CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger?
Date: Wed, 11 Jun 2008 16:57:50 -0400 [thread overview]
Message-ID: <20080611205749.GA25194@fieldses.org> (raw)
In-Reply-To: <20080611160947.5f08fb16-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Wed, Jun 11, 2008 at 04:09:47PM -0400, Jeff Layton wrote:
> On Wed, 11 Jun 2008 15:52:22 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
> > I'm probably missing something fundamental--why doesn't
> > /proc/slab_allocators show any results for size-x where x >= 4096?
> >
> > Someone's seeing a performance problem with the linux nfs server. One
> > of the symptoms is the "size-4096" slab cache seems to be out of
> > control. I assumed that meant that memory allocated by kmalloc() might
> > be leaking, so figured it might be interesting to turn on
> > CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that does is list
> > kmalloc() callers in /proc/slab_allocators. But that doesn't seem to be
> > showing any results for size-4096. Can anyone provide a clue?
> > Thanks!
> >
> > --b.
> >
>
>
> Hmm...I've never used this, but in kmem_cache_alloc():
>
> /*
> * Enable redzoning and last user accounting, except for caches with
> * large objects, if the increased size would increase the object size
> * above the next power of two: caches with object sizes just above a
> * power of two have a significant amount of internal fragmentation.
> */
> if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> 2 * sizeof(unsigned long long)))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
>
>
> ...looks like it specifically excludes some caches.
Ah, I missed that! I'm a little confused as to how those flags behavior
affect the collection of the leak debugging data, but I can verify that
the below does result in size-4096 showing up in /proc/slab_allocators;
hopefully there's no more negative result than the performance penalty.
Norman, do you think you could try applying this and then trying again?
--b.
diff --git a/mm/slab.c b/mm/slab.c
index 06236e4..b379e31 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name, size_t size, size_t align,
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
+ if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
"Weathers, Norman R." <Norman.R.Weathers@conocophillips.com>
Subject: Re: CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger?
Date: Wed, 11 Jun 2008 16:57:50 -0400 [thread overview]
Message-ID: <20080611205749.GA25194@fieldses.org> (raw)
In-Reply-To: <20080611160947.5f08fb16@tleilax.poochiereds.net>
On Wed, Jun 11, 2008 at 04:09:47PM -0400, Jeff Layton wrote:
> On Wed, 11 Jun 2008 15:52:22 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
> > I'm probably missing something fundamental--why doesn't
> > /proc/slab_allocators show any results for size-x where x >= 4096?
> >
> > Someone's seeing a performance problem with the linux nfs server. One
> > of the symptoms is the "size-4096" slab cache seems to be out of
> > control. I assumed that meant that memory allocated by kmalloc() might
> > be leaking, so figured it might be interesting to turn on
> > CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that does is list
> > kmalloc() callers in /proc/slab_allocators. But that doesn't seem to be
> > showing any results for size-4096. Can anyone provide a clue?
> > Thanks!
> >
> > --b.
> >
>
>
> Hmm...I've never used this, but in kmem_cache_alloc():
>
> /*
> * Enable redzoning and last user accounting, except for caches with
> * large objects, if the increased size would increase the object size
> * above the next power of two: caches with object sizes just above a
> * power of two have a significant amount of internal fragmentation.
> */
> if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> 2 * sizeof(unsigned long long)))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
>
>
> ...looks like it specifically excludes some caches.
Ah, I missed that! I'm a little confused as to how those flags behavior
affect the collection of the leak debugging data, but I can verify that
the below does result in size-4096 showing up in /proc/slab_allocators;
hopefully there's no more negative result than the performance penalty.
Norman, do you think you could try applying this and then trying again?
--b.
diff --git a/mm/slab.c b/mm/slab.c
index 06236e4..b379e31 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name, size_t size, size_t align,
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
+ if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
next prev parent reply other threads:[~2008-06-11 20:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 18:50 Problems with large number of clients and reads Norman Weathers
2008-06-04 13:49 ` Chuck Lever
[not found] ` <76bd70e30806040649h53ab5d66x8c3423c551e94f77-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-06-04 14:13 ` Norman Weathers
2008-06-05 18:54 ` Norman Weathers
2008-06-06 14:44 ` Chuck Lever
2008-06-09 13:56 ` Weathers, Norman R.
2008-06-06 0:06 ` Dean Hildebrand
2008-06-09 13:20 ` Weathers, Norman R.
2008-06-06 16:09 ` J. Bruce Fields
2008-06-09 14:19 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C2977010155587-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-09 18:53 ` J. Bruce Fields
2008-06-10 14:30 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75D9F-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-10 17:16 ` J. Bruce Fields
2008-06-10 22:12 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DA3-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-11 18:46 ` J. Bruce Fields
2008-06-11 19:52 ` CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger? J. Bruce Fields
2008-06-11 19:52 ` J. Bruce Fields
2008-06-11 20:09 ` Jeff Layton
2008-06-11 20:09 ` Jeff Layton
[not found] ` <20080611160947.5f08fb16-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-06-11 20:57 ` J. Bruce Fields [this message]
2008-06-11 20:57 ` J. Bruce Fields
2008-06-11 22:46 ` Weathers, Norman R.
2008-06-11 22:46 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DAA-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-11 22:54 ` J. Bruce Fields
2008-06-11 22:54 ` J. Bruce Fields
2008-06-12 19:54 ` Weathers, Norman R.
2008-06-12 19:54 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DAE-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-13 20:15 ` J. Bruce Fields
2008-06-13 20:15 ` J. Bruce Fields
2008-06-13 21:53 ` Weathers, Norman R.
2008-06-13 21:53 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DB6-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-13 22:04 ` J. Bruce Fields
2008-06-13 22:04 ` J. Bruce Fields
2008-06-13 22:53 ` Weathers, Norman R.
2008-06-13 22:53 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DB7-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-16 17:43 ` J. Bruce Fields
2008-06-16 17:43 ` J. Bruce Fields
2008-06-19 15:53 ` Weathers, Norman R.
2008-06-19 15:53 ` Weathers, Norman R.
[not found] ` <0122F800A3B64C449565A9E8C297701002D75DD4-zIGg2qceuZx7uNL6xugVa6xOck334EZe@public.gmane.org>
2008-06-19 18:46 ` J. Bruce Fields
2008-06-19 18:46 ` J. Bruce Fields
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=20080611205749.GA25194@fieldses.org \
--to=bfields@fieldses.org \
--cc=Norman.R.Weathers-496aOtIFJR1B+Kdf37RAV9BPR1lH4CV8@public.gmane.org \
--cc=jlayton@poochiereds.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.