Messages in this thread | | | Date | Fri, 26 Apr 2013 14:42:32 +0000 | From | Christoph Lameter <> | Subject | Re: OOM-killer and strange RSS value in 3.9-rc7 |
| |
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.
Is there any way I can run a powerpc kernel that shows the issue on x86 with an emulator?
| |