Date: Tue, 3 Sep 2019 10:02:59 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@freebsd.org>, 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: <79c74018-1329-ee69-3480-e2f99821fa93@FreeBSD.org> In-Reply-To: <201909012222.x81MMh0F022462@repo.freebsd.org> References: <201909012222.x81MMh0F022462@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/09/2019 01:22, Mark Johnston wrote: > Author: markj > Date: Sun Sep 1 22:22:43 2019 > New Revision: 351673 > URL: https://svnweb.freebsd.org/changeset/base/351673 > > Log: > Extend uma_reclaim() to permit different reclamation targets. > > The page daemon periodically invokes uma_reclaim() to reclaim cached > items from each zone when the system is under memory pressure. This > is important since the size of these caches is unbounded by default. > However it also results in bursts of high latency when allocating from > heavily used zones as threads miss in the per-CPU caches and must > access the keg in order to allocate new items. > > With r340405 we maintain an estimate of each zone's usage of its > (per-NUMA domain) cache of full buckets. Start making use of this > estimate to avoid reclaiming the entire cache when under memory > pressure. In particular, introduce TRIM, DRAIN and DRAIN_CPU > verbs for uma_reclaim() and uma_zone_reclaim(). When trimming, only > items in excess of the estimate are reclaimed. Draining a zone > reclaims all of the cached full buckets (the previous behaviour of > uma_reclaim()), and may further drain the per-CPU caches in extreme > cases. > > Now, when under memory pressure, the page daemon will trim zones > rather than draining them. As a result, heavily used zones do not incur > bursts of bucket cache misses following reclamation, but large, unused > caches will be reclaimed as before. Mark, have you considered running UMA_RECLAIM_TRIM periodically, even without a memory pressure? I think that with such a periodic trimming there will be less need to invoke vm_lowmem(). Also, I think that we would be able to retire (or re-purpose) lowmem_period. E.g., the trimming would be done every lowmem_period, but vm_lowmem() would not be throttled. One example of the throttling of vm_lowmem being bad is its interaction with the ZFS ARC. When there is a spike in memory usage we want the ARC to adapt as quickly as possible. But at present the lowmem_period logic interferes with that. > Reviewed by: jeff > Tested by: pho (an earlier version) > MFC after: 2 months > Sponsored by: Netflix > Differential Revision: https://reviews.freebsd.org/D16667 -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79c74018-1329-ee69-3480-e2f99821fa93>