http://bugzilla.suse.com/show_bug.cgi?id=998850
http://bugzilla.suse.com/show_bug.cgi?id=998850#c23
--- Comment #23 from Michal Hocko
Created attachment 694754 [details] New stacktrace with longer runtime
OK, the generic slab cache has grown quite some slabinfo.before:kmalloc-4096 2726 2738 4096 1 1 : tunables 24 12 8 : slabdata 2726 2738 36 slabinfo.after:kmalloc-4096 18333 18333 4096 1 1 : tunables 24 12 8 : slabdata 18333 18333 0 which is ~60M, not a disaster and it might be completely reasonable size for your workload. Let's see what the stack traces have to say. $ zgrep "=> kmem_cache_alloc" -A1 stacktrace.gz | grep -v "kmem_cache_alloc\|--" | sort | uniq -c 59122 => getname_flags 215 => getname_kernel 1584 => mempool_alloc 10 => SyS_getcwd So the vast majority is in getname* and some of them are in mempool_alloc. The first one shouldn't go to the generic 4k cache and the later doesn't add up to explain the increased size. So I think we are looking at a wrong tracepoint all the time. Let's try to hook into events/kmem/kmalloc and events/kmem/kmalloc_node, you will enable them the same way as the previous trace point. Plus put the same filter for bytes_alloc == 4096 for both trace points. I am sorry, I could have thought about that earlier. -- You are receiving this mail because: You are on the CC list for the bug.