Date: Wed, 4 Sep 2019 09:27:00 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@freebsd.org>, Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm Message-ID: <8b049a33-e844-1a47-2be1-c267946b8f95@FreeBSD.org> In-Reply-To: <20190903220106.GB26733@raichu> References: <201909012222.x81MMh0F022462@repo.freebsd.org> <79c74018-1329-ee69-3480-e2f99821fa93@FreeBSD.org> <20190903161427.GA38096@zxy.spb.ru> <20190903220106.GB26733@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/09/2019 01:01, Mark Johnston wrote: > Some of the vm_lowmem eventhandlers probably shouldn't be called each > time the page daemon scans the inactive queue (every 0.1s under memory > pressure). ufsdirhash_lowmem and mb_reclaim in particular don't seem > like they need to be invoked very frequently. We could easily define > multiple eventhandlers to differentiate between these cases, though. My proposal is to run uma_reclaim(UMA_RECLAIM_TRIM) before invoking vm_lowmem. If that reclaims "enough" memory, then do not call vm_lowmem at all. Oh, and I have a related question. Say, a zone has X items in use and Y items in cache. After running vm_lowmem the composition changes to X - C and Y + C respectively. Then we run uma_reclaim(UMA_RECLAIM_TRIM). Question: is that guaranteed to free at least C items? I am thinking about a possibility that the zone's workset size is estimated to be at least X (and maybe even more than X + Y). In that case UMA_RECLAIM_TRIM won't free those C items, they will stay in the cache. So, it seems like releasing them was in vain, at least for the immediate reclaim. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8b049a33-e844-1a47-2be1-c267946b8f95>