I've been tuning NFS hosted dual PII 400 Mhz/256 Mbyte machines and found
that the primary
kernel compilation bottleneck is excessive amounts of NFS lookup calls. Live
NFS lookups are done
on info that is cached!
Instrumentation reveals that d_time is not updated in nfs_lookup_revalidate
causing the
current time-out of 5*HZ to always trigger. Adding a nfs_renew_times before
out_valid:
in nfs_lookup_revalidate() fixes this.
The test machine is NFS hosted from a server with 400 Mbyte of SDRAM at 100
Mb/s.
Without this fix the reported CPU usage from 'time' is 75-90% CPU or less.
With this fix the CPU usage increases to 140-150%.
However, caching is still not near the point where the 256 Mbyte of SDRAM is
used!
There are two problems, first a
echo 50 60 75 > /proc/sys/vm/pagecache
is needed to allow the page cache to be used (though it seems as if this
should not be needed, e.g.,
there are memory around so the _max_ should be the limit ...)
The second is more subtle, the inode/dcache is hovering at 500 entries.
A kernel compile needs a higher working set then this. It seems as if NFS
file access fails
to increase the inode cache size (the dentry cache size tracks the inode
cache size).
Now, artificially increasing the size of the inode cache by using 'find
<large-directory>' on a hard disk,
which apparently triggers an increase in the inode buffer size, causes the
kernel compile to yield CPU
usage above 170%. Things stays this way until reboot!
Any comments on this?
Ove
PS; isn't this like a reverse "rusting" effect :-)
-
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/