http://bugzilla.suse.com/show_bug.cgi?id=998850
http://bugzilla.suse.com/show_bug.cgi?id=998850#c19
--- Comment #19 from Vlastimil Babka
We can also check who is calling the allocator then we have basically the same picture as previously: $ zgrep -A 1 "=> kmem_cache_alloc" stacktrace.gz | grep -v "kmem_cache_alloc\|--" | sort | uniq -c 53432 => getname_flags 42 => getname_kernel 164 => mempool_alloc 34 => SyS_getcwd
The same but limited to gkrellm process, which is the main suspect here: caster@linux-0o17:~> xzcat /tmp/stacktrace.xz | grep gkrellm -A 10 | grep "=> kmem_cache_alloc" -A1 | grep -v "kmem_cache_alloc" | grep "=>" | less | sort | uniq -c 3231 => getname_flags 3 => getname_kernel 41 => mempool_alloc The trace is 168 seconds long (21109 - 20941). With the estimated leakage of 10 pages/seconds, we are looking for an event that occured ~1700 times. Nothing such pops out yet. However, the first time gkrellm appears is at 21093.108228, so it was running only for the last 16 seconds of the whole trace? That would mean 160 events. mempool_alloc with 164 is very close, but that's spread over the whole trace... -- You are receiving this mail because: You are on the CC list for the bug.