The inode reclaim is too aggressive at present - it is causing the
shootdown of lots of recently-used pagecache.  Simple testcase: run a
huge `dd' while running a concurrent `watch -n1 cat /proc/meminfo'.
The program text for `cat' gets loaded from disk once per second.

This is in fact because the dentry_unused reclaim is too aggressive.

(The general approach to inode reclaim is that it _not_ happen at the
inode level.  All the aging and lru activity happens at the dcache
level.)

The problem is partly due to a bug: shrink_dcache_memory() is returning
the *total* number of dentries to the VM, rather than the number of
unused dentries.

This patch fixes that, and goes a little further.

We do want to keep some unused dentries around.  Reclaiming the last
few thousand dentries is pretty pointless, and will allow reclaim of
the last few thousand inodes and their attached pagecache.

So the algorithm I have used is to not allow the number of unused
dentries to fall below the number of used ones.  This keeps a
reasonable number of dentries in cache while providing a level of
scaling to the system size and the current system activity.

(Magic number alert: why not pin nr_unused to seven times nr_used,
rather than one times??)

shrink_dcache_memory() has been changed to tell the VM that the number
of shrinkable dentries is:

	zero if (nr_unused < nr_used)
	otherwise (nr_unused - nr_used)

so when there is memory pressure the VM will prune the unused dentry
cache down to the size of the used dentry cache, but not below that.

The patch also arranges (awkwardly) for all modifications of
dentry_stat.nr_dentry to occur inside dcache_lock - it was racy.