an easy (?) question on namecache sizing

[Kirk McKusick]

> Date: Thu, 5 Nov 2015 21:56:48 +0200
> From: Konstantin Belousov <kostikbel at gmail.com>
> To: Kirk McKusick <mckusick at mckusick.com>
> Subject: Re: an easy (?) question on namecache sizing
> Cc: fs at freebsd.org
> 
> On Thu, Nov 05, 2015 at 10:56:55AM -0800, Kirk McKusick wrote:
>> 
>> 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) {
>> +		wantfreevnodes = desiredvnodes / 4;
>>  		vfs_hash_changesize(desiredvnodes);
>>  		cache_changesize(desiredvnodes);
>>  	}
>>  	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.
> 
> I think the idea is right, but the implementation is not. Just changing
> wantfreevnodes after desirevnodes was reduced, creates a window where an
> other thread could see small value for desiredvnodes, but large value
> for wantfreevnodes. Then, e.g. vlrureclaim() would go wild. IMO it should
> ensure that the observable values are non-contradictory.

Does moving the setting of wantfreevnodes before the cache size changes
(as redone above) close the window enough? The vlrureclaim() function
operates slowly enough that a brief period of inconsistency seems
unimportant. Changing desiredvnodes happens very rarely. And at the moment
we are not correcting wantfreevnodes at all. Or am I missing some key point?

	Kirk McKusick