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
--Sig_/F/51+cUv.CodI73CJOgx1Eg
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
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.
> >=20
> > According to uma.h, uma_reclaim() "should only be called by
> > the page out daemon", presumably because of the overhead
> > and side-effects.
> >=20
> > I've been using this patch for a couple of weeks and didn't
> > notice any regressions:
> >=20
> > 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 <=3D desire=
dvnodes)
> > - uma_reclaim();
> > + if (onumvnodes > desiredvnodes && numvnodes <=3D desire=
dvnodes) {
> > + zone_drain(vnode_zone);
> > + zone_drain(vnodepoll_zone);
> > + } =20
> 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 attac=
hed
> 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 ?
>=20
> Practically, significant part of the kernel memory allocations is rooted
> in the vnode handling, and when we shrink the vnode cache due to neccessi=
ty,
> 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
--Sig_/F/51+cUv.CodI73CJOgx1Eg
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAldhVTwACgkQBYqIVf93VJ0LwACghPx3MPeTrlgc1BB+gHqM8jVs
Ty0An2IYn4ctqbXkU5Zznu+eu9UKJF93
=yNg5
-----END PGP SIGNATURE-----
--Sig_/F/51+cUv.CodI73CJOgx1Eg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160615151644.2cb4bb18>