http://oss.sgi.com/bugzilla/show_bug.cgi?id=209
------- Additional Comments From lord@xxxxxxx 2003-11-12 07:05 PDT -------
A few of comments on this bug:
From the attachment tdickson made, the problem here is the linux inode
cache (which shows up as linvfs_icache). The kernel's prune_icache
and prune_dcache code are responsible for cleaning this up. The linux
dcache has a problem in that a directory dcache entry cannot be
reclaimed if the directory has an entry. This pins the whole page
into the cache, it also pins the inode and xfs inode into memory.
On a machine with lots of memory, what I have seen happen is that
when page reclaim becomes active, it can often get memory out of
the page cache of files, if this succeeds it does not attempt to
shrink the dcache and icache at all. If the pages are being claimed
from the page cache to create more inodes you end up with a huge
imbalance in the memory usage on the system. I think this is
the fundamental problem, it creates an imbalance in the system
which makes things really bad before you can get out of it.
Running without swap is a baad thing, no matter how much memory you
have. This is probably doubly true if the oom killer is present.
There is a memory overcommit systune /proc/sys/vm/overcommit_memory
try playing with that to change behavior.
The oom killer has come in and out of the kernel over time, I thought
it had recently been removed again because of its tendency to kill
important processes.
In the most recent kernels the linux inode cache entries are significantly
smaller. XFS does not use the union at the end of the inode and does not
allocate it at all if the right code is in place. I do not honestly
know if this made it into Marcelo or Linus's trees.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|