Date: Thu, 5 Nov 2015 21:56:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: Bruce Evans <brde@optusnet.com.au>, fs@freebsd.org Subject: Re: an easy (?) question on namecache sizing Message-ID: <20151105195648.GK2257@kib.kiev.ua> In-Reply-To: <201511051856.tA5Iutge064958@chez.mckusick.com> References: <20151103090448.GC2257@kib.kiev.ua> <201511051856.tA5Iutge064958@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 05, 2015 at 10:56:55AM -0800, Kirk McKusick wrote:
> > Date: Tue, 3 Nov 2015 11:04:48 +0200
> > From: Konstantin Belousov <kostikbel@gmail.com>
> > To: Kirk McKusick <mckusick@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.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151105195648.GK2257>