Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Nov 2015 22:52:55 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Kirk McKusick <mckusick@mckusick.com>
Cc:        fs@freebsd.org
Subject:   Re: an easy (?) question on namecache sizing
Message-ID:  <20151105205255.GL2257@kib.kiev.ua>
In-Reply-To: <201511052025.tA5KPcLF066724@chez.mckusick.com>
References:  <20151105195648.GK2257@kib.kiev.ua> <201511052025.tA5KPcLF066724@chez.mckusick.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 05, 2015 at 12:25:38PM -0800, Kirk McKusick wrote:
> > Date: Thu, 5 Nov 2015 21:56:48 +0200
> > From: Konstantin Belousov <kostikbel@gmail.com>
> > To: Kirk McKusick <mckusick@mckusick.com>
> > Subject: Re: an easy (?) question on namecache sizing
> > Cc: fs@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?

I think wantfreevnodes should be set before the cache size changes when
desiredvnodes is decreased, but kept at the place in your patch for the
increasing case.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151105205255.GL2257>