From owner-freebsd-hackers@freebsd.org Wed Jun 15 13:31:36 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48A46A31951 for ; Wed, 15 Jun 2016 13:31:36 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03D71166B for ; Wed, 15 Jun 2016 13:31:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.172.85] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1bDAhT-0002x5-Cp for freebsd-hackers@freebsd.org; Wed, 15 Jun 2016 15:17:43 +0200 Date: Wed, 15 Jun 2016 15:16:44 +0200 From: Fabian Keil 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/F/51+cUv.CodI73CJOgx1Eg"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 13:31:36 -0000 --Sig_/F/51+cUv.CodI73CJOgx1Eg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov 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--