Re: v3.4-rc2 out-of-memory problems (was Re: 3.4-rc1 sticks-and-crashs)

From: Linus Torvalds
Date: Sun Apr 08 2012 - 23:11:50 EST


On Sun, Apr 8, 2012 at 7:50 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 8 Apr 2012 19:42:31 -0700 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> > Apr __8 20:29:11 werner kernel: Normal free:44004kB min:44012kB low:55012kB
>> > high:66016kB active_anon:0kB inactive_anon:0kB active_file:132kB
>> > inactive_file:140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
>> > present:885944kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
>> > slab_reclaimable:13068kB slab_unreclaimable:147784kB kernel_stack:628952kB
>> > pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1376
>> > all_unreclaimable? yes
>
> That's claiming that 600MB of ZONE_NORMAL is being used for kernel stacks.

Well, that would certainly eat up memory that is hard to get back.

Werner - if you can reproduce this, can you get a "ps axl" or similar
when it starts happening? Or probably even long before, since it
probably starts long long earlier.

Or does anybody see anything that keeps thread counts raised so that
"free_task()" doesn't get done. kernel/profoe.c does that
"profile_handoff_task()" thing - but only oprofile and the android
low-memory-killer logic seems to use it though. But that's exactly the
kind of thing that Werner's "configure everything" might enable -
Werner?

What else would do this? I'd suspect the /proc code, but that grabs
the mm_struct, and those particular changes were pre-3.3 anyway.

Adding Oleg just in case he has any ideas about process code changes
(or some usermodehelper thing that leaks processes, or whatever).

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