[lkml]   [2012]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: v3.4-rc2 out-of-memory problems (was Re: 3.4-rc1 sticks-and-crashs)
On Sun, Apr 8, 2012 at 7:50 PM, Andrew Morton <> wrote:
> On Sun, 8 Apr 2012 19:42:31 -0700 Linus Torvalds <> 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 -

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).


 \ /
  Last update: 2012-04-09 05:15    [W:0.096 / U:8.840 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site