On 02/25/2013 10:39 PM, Jonathan Woithe wrote: > On Wed, Feb 13, 2013 at 07:14:50AM -0800, Dave Hansen wrote: >> David's analysis looks spot-on. The only other thing I'll add is that >> it just looks weird that all three kmalloc() caches are so _even_: >> >>>> kmalloc-128 1234556 1235168 128 32 1 : tunables 0 0 0 : slabdata 38599 38599 0 >>>> kmalloc-64 1238117 1238144 64 64 1 : tunables 0 0 0 : slabdata 19346 19346 0 >>>> kmalloc-32 1236600 1236608 32 128 1 : tunables 0 0 0 : slabdata 9661 9661 0 >> >> It's almost like something goes and does 3 allocations in series and >> leaks them all. ... > Given these observations it seems that 2.6.35.11 was leaking memory, > probably as a result of a bug in the fork() execution path. At this stage > kmemleak is not showing the same recurring problem under 3.7.9. Your kmemleak data shows that the leaks are always from either 'struct cred', or 'struct pid'. Those are _generally_ tied to tasks, but you only have a couple thousand task_structs. My suspicion would be that something is allocating those structures, but a refcount got leaked somewhere. 2.6.35.11 is about the same era that this code went in: http://lists.linux-foundation.org/pipermail/containers/2010-June/024720.html and it deals with both creds and 'struct pid'. Eric, do you recall any bugs like this that got fixed along the way? I do think it's fairly safe to assume that 3.7.9 doesn't have this bug. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>