an easy (?) question on namecache sizing

[Kirk McKusick]

> Date: Tue, 3 Nov 2015 11:04:48 +0200
> From: Konstantin Belousov <kostikbel at gmail.com>
> To: Kirk McKusick <mckusick at mckusick.com>
> Subject: Re: an easy (?) question on namecache sizing
> 
> Free vnodes could be freed in the soft fashion by vnlru daemon, or in
> hard manner, by the getnewvnode(), when the max for the vnode count is
> reached. The 'soft' way skips vnodes which are directories, to make it
> more probable that vn_fullpath() would succeed, and also has threshold
> for the count of cached pages. The 'hard' way waits up to 1 sec for
> the vnlru daemon to succeed, before forcing a recycle for any vnode,
> regardless of the 'soft' stoppers. This causes the ticking behaviour of
> the system when only one vnode operation in single thread succeeds in a
> second.
> 
> Large wantfreevnodes value is the safety measure to prevent the tick
> steps in practice. My initial reaction on the complain was to just
> suggest to increase desiredvnodes, at least this is what I do on
> machines where there is a lot of both KVA and memory and intensive file
> loads are expected.

I propose that we update wantfreevnodes in sysctl_update_desiredvnodes()
so that it tracks the change in desiredvnodes:

Index: /sys/kern/vfs_subr.c
===================================================================
--- /sys/kern/vfs_subr.c	(revision 290387)
+++ /sys/kern/vfs_subr.c	(working copy)
@@ -293,6 +293,7 @@
 	if (old_desiredvnodes != desiredvnodes) {
 		vfs_hash_changesize(desiredvnodes);
 		cache_changesize(desiredvnodes);
+		wantfreevnodes = desiredvnodes / 4;
 	}
 	return (0);
 }

Otherwise bumping up desiredvnodes will be less effective than expected.

I see that Bruce has also suggested this change in his more extensive
revisions.

	Kirk McKusick