linux-kernel - Re: OOM-killer and strange RSS value in 3.9-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 26 Apr 2013 14:24:36 +0800
From:	Han Pingtian <hanpt@...ux.vnet.ibm.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Christoph Lameter <cl@...ux.com>, mhocko@...e.cz,
	penberg@...nel.org, rientjes@...gle.com, linux-mm@...ck.org
Subject: Re: OOM-killer and strange RSS value in 3.9-rc7

On Thu, Apr 25, 2013 at 06:24:05PM +0000, Christoph Lameter wrote:
> On Thu, 25 Apr 2013, Han Pingtian wrote:
> 
> > > A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
> > > useful.
> > >
> > I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
> > will attach it to this mail.
> 
> Ok that looks like a lot of objects were freed from slab pages but the
> slab pages were not freed.
> 
> looking at kmalloc-8192 we have
> 
> Total capacity of the slab cache is 27k objects but only 508 are in use.
> 
> Looks like slab pages are not freed when all objects in them have been
> released.
> 
> The relevant portion of code that do the freeing are in
> 
> mm/slub.c::unfreeze_partials()
> 
> 		if (unlikely(!new.inuse && n->nr_partial > s->min_partial)) {
>                         page->next = discard_page;
>                         discard_page = page;
>                 } else {
>                         add_partial(n, page, DEACTIVATE_TO_TAIL);
>                         stat(s, FREE_ADD_PARTIAL);
>                 }
> 
> 
> ..
> 
>        while (discard_page) {
>                 page = discard_page;
>                 discard_page = discard_page->next;
> 
>                 stat(s, DEACTIVATE_EMPTY);
>                 discard_slab(s, page);
>                 stat(s, FREE_SLAB);
>         }
> 
> and mm/slub.c::__slab_free()
> 
>      if (unlikely(!new.inuse && n->nr_partial > s->min_partial))
>                 goto slab_empty;
> 
> 
> Could you verify the values of nr_partial and min_partial and verify that
> the free paths are actually used?

Could you give me some hints about how to verify them? Only I can do is
adding two printk() statements to print the vaules in those two
functions:

--------------------------------------------------------------------------------
diff --git a/mm/slub.c b/mm/slub.c
index 4aec537..d08d62d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1915,6 +1915,9 @@ static void unfreeze_partials(struct kmem_cache *s,
                                new.freelist, new.counters,
                                "unfreezing slab"));
 
+               if (strcmp(s->name, "kmalloc-8192") == 0) {
+                       printk(KERN_INFO "In unfreeze_partials(); kmalloc-8192: n->nr_partial=%lu, s->min_partial
+                }
                if (unlikely(!new.inuse && n->nr_partial > s->min_partial)) {
                        page->next = discard_page;
                        discard_page = page;
@@ -2536,6 +2539,10 @@ static void __slab_free(struct kmem_cache *s, struct page *page,
                 return;
         }
 
+       if (strcmp(s->name, "kmalloc-8192") == 0) {
+               printk(KERN_INFO "In __slab_free(); kmalloc-8192: n->nr_partial=%lu, s->min_partial=%lu\n", n->nr
+       }
+
        if (unlikely(!new.inuse && n->nr_partial > s->min_partial))
                goto slab_empty;

--------------------------------------------------------------------------------

And looks like only printk() in __slab_free() is invoked. I got about 6764 
lines of something like this:

--------------------------------------------------------------------------------
Apr 26 01:04:05 riblp3 kernel: [    6.969775] In __slab_free(); kmalloc-8192: n->nr_partial=2, s->min_partial=6
Apr 26 01:04:05 riblp3 kernel: [    6.970154] In __slab_free(); kmalloc-8192: n->nr_partial=3, s->min_partial=6
Apr 26 01:04:05 riblp3 kernel: [    6.979489] In __slab_free(); kmalloc-8192: n->nr_partial=4, s->min_partial=6
Apr 26 01:04:05 riblp3 kernel: [    6.979823] In __slab_free(); kmalloc-8192: n->nr_partial=5, s->min_partial=6
Apr 26 01:04:05 riblp3 kernel: [    9.500383] In __slab_free(); kmalloc-8192: n->nr_partial=7, s->min_partial=6
Apr 26 01:04:05 riblp3 kernel: [    9.509736] In __slab_free(); kmalloc-8192: n->nr_partial=7, s->min_partial=6
Apr 26 01:04:08 riblp3 kernel: [   42.314395] In __slab_free(); kmalloc-8192: n->nr_partial=100, s->min_partial=6
Apr 26 01:04:08 riblp3 kernel: [   42.410333] In __slab_free(); kmalloc-8192: n->nr_partial=100, s->min_partial=6
Apr 26 01:04:09 riblp3 kernel: [   43.411851] In __slab_free(); kmalloc-8192: n->nr_partial=339, s->min_partial=6
Apr 26 01:04:09 riblp3 kernel: [   43.411980] In __slab_free(); kmalloc-8192: n->nr_partial=338, s->min_partial=6
Apr 26 01:04:09 riblp3 kernel: [   43.412083] In __slab_free(); kmalloc-8192: n->nr_partial=337, s->min_partial=6
--------------------------------------------------------------------------------
The s->min_partial is always "6" and most of n->nr_partial is bigger than 
its partner of the same line.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/