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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 26, 2013 at 02:42:32PM +0000, Christoph Lameter wrote:
> On Fri, 26 Apr 2013, Han Pingtian wrote:
> 
> > 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:
> 
> Ok thats good. nr->partial needs to be bigger than min_partial in order
> for frees to occur. So they do occur.
> 
> > 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.
> 
> Thats the way it should be. But the mystery is still there. Why do the
> pages not get freed? Can you add a printk in __free_slab to verify that it
> actually gets called? Print s->name to see which slab is affected by the
> free.
> 
I added a printk() like this:

@@ -1388,6 +1388,8 @@ static void __free_slab(struct kmem_cache *s, struct page *page)
        int order = compound_order(page);
        int pages = 1 << order;
 
+       printk(KERN_INFO "__free_slab(): %s\n", s->name);
+
        if (kmem_cache_debug(s)) {
                void *p;

and it is called so many times that the boot cannot be finished. So
maybe the memory isn't freed even though __free_slab() get called?


> Is there any way I can run a powerpc kernel that shows the issue on x86
> with an emulator?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]