> -----Original Message----- > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > Sent: Wednesday, June 11, 2008 3:58 PM > To: Jeff Layton > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; > Weathers, Norman R. > Subject: Re: CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger? > > 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@xxxxxxxxxxxx> 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. I will try and get it patched and retested, but it may be a day or two before I can get back the information due to production jobs now running. Once they finish up, I will get back with the info. Thanks everyone for looking at this, by the way! > > > 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)) > Norman Weathers -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
