vnlru_proc() draining unrelated uma zones

[Fabian Keil]

Konstantin Belousov <kostikbel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20160615/6ca7bb0a/attachment.sig>