Messages in this thread | | | Date | Tue, 21 Jul 1998 01:04:48 -0400 (EDT) | From | "Benjamin C.R. LaHaise" <> | Subject | inode caching [sub-optimal] & nfs caching [not present] |
| |
Hello all,
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
| |