On Sat, 2012-07-21 at 21:04 -0700, Alan W. Irwin wrote: > On 2012-07-21 23:24+0100 Ben Hutchings wrote: > > > Thanks to the detailed report. Memory leaks are sadly common, and many > > have been fixed since Linux 2.6.32. I don't think it's practical to > > attempt to match up those many fixes against your list of applications. > > Hi Ben: > > Thanks for responding. > > Could you please attempt to verify the problem (by periodically > checking kmalloc-32 in /proc/slabinfo on machines you have access to > for a few days) to get a feel for how common this issue is? [...] It seems like there should normally be < 10,000 active kmalloc-32 objects, whereas with this bug there will soon be many more than that. So I'll just look to see where that is the case. My own sample of 1 server doesn't have this problem: $ cat /proc/version Linux version 2.6.32-5-486 (Debian 2.6.32-45) (email@example.com) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sun May 6 03:29:22 UTC 2012 $ uptime 05:50:10 up 46 days, 5:15, 6 users, load average: 0.16, 0.73, 0.97 $ grep kmalloc-32 /proc/slabinfo kmalloc-32 2640 2944 32 128 1 : tunables 0 0 0 : slabdata 23 23 0 > For > example, it might occur for _all_ desktop users who run > kernel-2.6.32-5-amd64 and not have much to do with my own particular > application mix. After all, this is not an ordinary memory leak. > Instead, it is a leak in a special kind of memory that the kernel > controls directly, and presumably this kernel bug is exercised by just > some subset of the normal kernel calls. It is almost certainly rather more subtle than that, and may be associated with a particular filesystem or driver. [...] > Of course, that computer essentially runs nothing but an X server so > that is a very limited application mix and a heavier application mix > might trigger the issue. On the other hand, the problem might be > limited just to 64-bit hardware. So monitoring /proc/slabinfo on both > 32-bit and 64-bit machines running 2.6.32 is required to help pin this down. Possible. I don't have any 64-bit systems running the 'squeeze' kernel based on Linux 2.6.32 any more. But I can check various Debian developer machines: busoni (amd64): no cilea (amd64): no paganini (amd64): no piatti (amd64): no popov (amd64): no powell (amd64): no ravel (amd64): no respighi (amd64): no ries (amd64): no stabile (amd64): no And a few other architectures: master (i386): no samosa (i386): no senfl (i386): no widor (i386): no agricola (armel): no smetana (sparc): no zelenka (s390): no Ben. -- Ben Hutchings 73.46% of all statistics are made up.
Description: This is a digitally signed message part