From owner-freebsd-fs@freebsd.org Mon May 20 16:40:26 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80C8E15B2892; Mon, 20 May 2019 16:40:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 2016786C18; Mon, 20 May 2019 16:40:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1hSlKg-00010C-GH; Mon, 20 May 2019 19:40:14 +0300 Date: Mon, 20 May 2019 19:40:14 +0300 From: Slawa Olhovchenkov To: Ian Lepore Cc: lev@FreeBSD.org, freebsd-fs@freebsd.org, freebsd-hackers@FreeBSD.org, Alexander Motin Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me - second potential problem Message-ID: <20190520164014.GA47119@zxy.spb.ru> References: <369cb1e9-f36a-a558-6941-23b9b811825a@FreeBSD.org> <8160c9149c04d2b622292abf582bcbb9a541d2ed.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8160c9149c04d2b622292abf582bcbb9a541d2ed.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 2016786C18 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.57 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.909,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.88)[0.885,0]; IP_SCORE(0.00)[country: RU(0.01)]; MX_GOOD(-0.01)[zxy.spb.ru]; NEURAL_SPAM_LONG(0.88)[0.882,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 16:40:26 -0000 On Mon, May 20, 2019 at 10:20:45AM -0600, Ian Lepore wrote: > On Mon, 2019-05-20 at 19:05 +0300, Lev Serebryakov wrote: > > I'm looking at last commit to > > 'sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c' (r345200) and > > have another question. > > > > Here are such code: > > > > 4960 /* > > 4961 * Kick off asynchronous kmem_reap()'s of all our > > caches. > > 4962 */ > > 4963 arc_kmem_reap_soon(); > > 4964 > > 4965 /* > > 4966 * Wait at least arc_kmem_cache_reap_retry_ms between > > 4967 * arc_kmem_reap_soon() calls. Without this check it is > > possible to > > 4968 * end up in a situation where we spend lots of time > > reaping > > 4969 * caches, while we're near arc_c_min. Waiting here > > also > > gives the > > 4970 * subsequent free memory check a chance of finding > > that the > > 4971 * asynchronous reap has already freed enough memory, > > and > > we don't > > 4972 * need to call arc_reduce_target_size(). > > 4973 */ > > 4974 delay((hz * arc_kmem_cache_reap_retry_ms + 999) / > > 1000); > > 4975 > > > > But looks like `arc_kmem_reap_soon()` is synchronous on FreeBSD! So, > > this `delay()` looks very wrong. Am I right? > > > > Looks like it should be `#ifdef illumos`. > > > > One of the things arc_kmem_reap_soon() does is call > dnlc_reduce_cache(), and that sets a variable and does a condition > variable broadcast, presumably causing other threads to wake up and do > some work. So, presumably the delay (which appears to really be a call > to pause(9) on freebsd) allows time for that async work to happen > before calling arc_available_memory(). This call perform before any kmem reap and only conditional by arc_meta_used>=arc_meta_limit. In any way kmem reap is very long operation, longest any work in arc_dnlc_evicts_thread() (vnlru_free()).