Messages in this thread | | | Date | Wed, 03 Feb 1999 15:46:39 -0500 | From | Tomasz Przygoda <> | Subject | Re: [showstopper] Memory leak in 2.2.1 |
| |
Hi there,
sidekick:~# for one in /proc/sys/fs/*; do echo $one : `cat $one`; done /proc/sys/fs/dentry-state : 0 96658 45 0 0 0 /proc/sys/fs/dquot-max : 0 /proc/sys/fs/dquot-nr : 0 0 /proc/sys/fs/file-max : 7168 /proc/sys/fs/file-nr : 4860 3113 7168 /proc/sys/fs/inode-max : 20480 /proc/sys/fs/inode-nr : 1268624 3 /proc/sys/fs/inode-state : 1268624 9 1 0 0 0 0 /proc/sys/fs/super-max : 256 /proc/sys/fs/super-nr : 6
Does the above fall into the same category? I'm talking about the inode-nr and inode-state numbers - they are ridiculously big to me. The numbers for inode-max and file-max are slightly bumped up. Kernel is 2.2.1. More details uppon request :).
Alexander Viro wrote:
> On Wed, 3 Feb 1999, Oleg Drokin wrote: > > > Seems that inode cache that grows in inode.c:419 is never shrinked. > > What??? Wait... it's grow_inodes() and it looks like we never shrink the > damned icache again. Looks like it was always so with possible exception > of 2.1.36-2.1.42 when we used slab instead of bare pages. Damn. It's not a > leak per se - we just never shrink icache. Now, the fact that you managed > to grow it that large may mean that there is an inode leak, but that's > another story. What is the number of dirty inodes, BTW? They can't be > reused until they are cleaned.
Thanks!
-- Tomek, "Office'97, Windows'98 - every Microsoft product has an expiration date."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |