Date: Wed, 15 Jun 2016 15:16:44 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-hackers@freebsd.org Subject: Re: vnlru_proc() draining unrelated uma zones Message-ID: <20160615151644.2cb4bb18@fabiankeil.de> In-Reply-To: <20160615131024.GA38613@kib.kiev.ua> References: <20160615140516.3cba6001@fabiankeil.de> <20160615131024.GA38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Konstantin Belousov <kostikbel@gmail.com> wrote:
> On Wed, Jun 15, 2016 at 02:05:16PM +0200, Fabian Keil wrote:
> > While looking into two uma-related issues[0] I noticed that
> > vnlru_proc() is calling uma_reclaim() even though the intention
> > seems to be to merely drain the vnode-related zones.
> >
> > According to uma.h, uma_reclaim() "should only be called by
> > the page out daemon", presumably because of the overhead
> > and side-effects.
> >
> > I've been using this patch for a couple of weeks and didn't
> > notice any regressions:
> >
> > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
> > index 2767826..2c65ce1 100644
> > --- a/sys/kern/vfs_subr.c
> > +++ b/sys/kern/vfs_subr.c
> > @@ -1107,8 +1107,10 @@ vnlru_proc(void)
> > vfs_unbusy(mp);
> > }
> > mtx_unlock(&mountlist_mtx);
> > - if (onumvnodes > desiredvnodes && numvnodes <= desiredvnodes)
> > - uma_reclaim();
> > + if (onumvnodes > desiredvnodes && numvnodes <= desiredvnodes) {
> > + zone_drain(vnode_zone);
> > + zone_drain(vnodepoll_zone);
> > + }
> You listed two obvious zones which cache allocations related to vnodes,
> but there are much more. E.g. on some systems there are FFS inodes attached
> to most vnodes, on other there are znodes. What about rangelocks, fifos,
> namecache data etc ? What about malloc zones where some other allocs
> to handle vnodes are done ?
>
> Practically, significant part of the kernel memory allocations is rooted
> in the vnode handling, and when we shrink the vnode cache due to neccessity,
> we should shrink that second-level caches as well. Since it is very hard
> to properly enumerate that items, the shortcut is used.
I see. Thanks for the explanation.
Fabian
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAldhVTwACgkQBYqIVf93VJ0LwACghPx3MPeTrlgc1BB+gHqM8jVs
Ty0An2IYn4ctqbXkU5Zznu+eu9UKJF93
=yNg5
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160615151644.2cb4bb18>