Date: Wed, 15 Jun 2016 16:10:24 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: freebsd-hackers@freebsd.org Subject: Re: vnlru_proc() draining unrelated uma zones Message-ID: <20160615131024.GA38613@kib.kiev.ua> In-Reply-To: <20160615140516.3cba6001@fabiankeil.de> References: <20160615140516.3cba6001@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> if (done == 0) {
> if (force == 0 || force == 1) {
> force = 2;
>
> It also didn't seem to noticeable affect the issues I was investigating
> (the code is rarely executed on my systems), but calling uma_reclaim()
> still seems strange to me.
>
> Am I missing something?
>
> Fabian
>
> [0]
> "Prevent deadlocks when paging on GELI-encrypted devices":
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209759
> "[...] connections time out/ssh results in 'broken pipe'":
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209680
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160615131024.GA38613>