Playing around with 2.1.108 (these aspects should be the same with .109
and .110pre3), it looks like the inode cache isn't as agressive as it
should be -- just the opposite of what other people have reported, but
I've got ~80 megs free and I like dynamic caches. Do a 'cat
/proc/sys/fs/inode-nr' before and after several repetitions of 'ls
-lR>/dev/null' on a large directory tree (the kernel source works nicely).
Note that the inode cache doesn't grow far enough... Which means the
dentry cache can't be completely effective. Oh, this is assuming that
you've already done an echo 32768 >/proc/sys/fs/inode-max.
Second point on inode caching: once the system hits inode-max (it actually
goes over), it will not grow even if you increase inode-max. But this is
only a beauty mark. The obvious cause is in fs/inode.c:get_empty_inode
if (inodes_stat.nr_free_inodes < 16)
try_to_free_inodes(8);
Hmmm, let's try changing that 16 to 8... <pause> nope. Oh well, maybe
someone else has an idea. (I'm trying to work on swapping, not
filesystems! =)
Oh, and nfs caching is still *completely* broken, which is to say that
none of an inode's pages are retained -- a direct result of
nfs_put_inode's sole if. Could someone more familiar with the code in
fs/nfs/ take a look at fixing this? Or claim that it's impossible without
major reworking of the nfs client. Remember: 2.0 works beautifully under
these circumstances.
(/home/dot1 is an nfs mount from a 2.0 box w/unfsd-somethingorother)
blah@spiff:/home/dot1/blah > time dd if=mail.tar of=/dev/null bs=16k
241+1 records in
241+1 records out
real 0m4.596s
user 0m0.000s
sys 0m0.920s
blah@spiff:/home/dot1/blah > time dd if=mail.tar of=/dev/null bs=16k
241+1 records in
241+1 records out
real 0m4.594s
user 0m0.010s
sys 0m0.960s
blah@spiff:/home/dot1/blah >
As opposed to:
blah@spiff:/home/dot1/blah > ( sleep 1000 ) <mail.tar &
[1] 373
blah@spiff:/home/dot1/blah > time dd if=mail.tar of=/dev/null bs=16k
241+1 records in
241+1 records out
real 0m4.590s
user 0m0.000s
sys 0m0.890s
blah@spiff:/home/dot1/blah > time dd if=mail.tar of=/dev/null bs=16k
241+1 records in
241+1 records out
real 0m0.162s
user 0m0.000s
sys 0m0.160s
blah@spiff:/home/dot1/blah >
This really kills compiles over nfs...
-ben
-
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.altern.org/andrebalsa/doc/lkml-faq.html