On Thu, 6 Oct 2005, Robert Derr wrote:It looks like it is enabled. CONFIG_AUDITSYSCALL=y in .config, right?
I'm having a problem with a memory leak in the kernel. I'm running 2.6.13.3
from kernel.org on FC4 on a Dell Poweredge 2850 Duel Xeon 3ghz with 2GB RAM.
Just out of interest, do you have CONFIG_AUDIT_SYSCALL enabled? Does it go away if you disable it?
Also, what filesystems do you use? And if you runI'm not sure if I can find the action or behavior causing the problem. The server is the master node on a 14 computer cluster running a mesoscale weather forecasting package so there's a million things going on all the time. I guess I could write a program to compare all the processes running against the names_cache and look for any correlation.
while : ; do cat /proc/slabinfo | grep names_cache ; sleep 2; done
in one terminal, can you see if you can find any correlation to some particular action or behaviour that would seem to be part of leaking it?
It really shouldn't grow very big at all normally. Ie the counts are normally something like a few tens of entries used or whatever - all the allocations should basically be temporary, and your 200+ _thousand_ entries are way out of line.I'll look for those leak debugging patches.
If you can't find anything obvious, then we can try to figure out a way to just print out the contents of your name entries, I bet that would give a clue about who is allocating them. But there's also been various leak debugging patches out there that may help. Manfred may have pointers.
Linus