Date: Wed, 22 May 2019 12:49:48 -0400 From: Alexander Motin <mav@FreeBSD.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: lev@FreeBSD.org, Mark Johnston <markj@freebsd.org>, freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Commit r345200 (new ARC reclamation threads) looks suspicious to me - second potential problem Message-ID: <5ea6d9bc-4fd3-d8e6-adf4-513b4edc71e3@FreeBSD.org> In-Reply-To: <20190522161945.GE47119@zxy.spb.ru> References: <369cb1e9-f36a-a558-6941-23b9b811825a@FreeBSD.org> <20190520164202.GA2130@spy> <28c7430b-fb7c-6472-5c1b-fa3ff63a9e73@FreeBSD.org> <94d051a3-3427-7a5b-efe7-169cff2265d3@FreeBSD.org> <2a50e192-e672-7c87-178b-afd509a765df@FreeBSD.org> <20190522161945.GE47119@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22.05.2019 12:19, Slawa Olhovchenkov wrote: > On Wed, May 22, 2019 at 12:07:29PM -0400, Alexander Motin wrote: > >> On 22.05.2019 11:50, Lev Serebryakov wrote: >>> On 22.05.2019 18:19, Alexander Motin wrote: >>> >>>>>> But looks like `arc_kmem_reap_soon()` is synchronous on FreeBSD! So, >>>>>> this `delay()` looks very wrong. Am I right? >>>> >>>> Why is it wrong? >>> One second pause after synchronous operation to wait it completion? >> >> No. To rate-throttle them. This gives UMA a second to get back into >> minimally steady state after we ripped all caches from it. As I have >> told, we do not want to drain caches constantly in a tight loop, we want >> more or less steady state. > > And also (posible) additionaly delay arc_get_data_impl(). arc_get_data_impl() depends on arc_adjust_zthr, not on arc_reap_zthr, so it should not get blocked by this delay. That was the motivation for the threads splitting in the last rewrite. > This is incorrectly throttling implementation. I am not particularly defending ZFS doing its own reclamation, I'd more trust pagedaemon, but so far I haven't seen any memory pressure issues after I committed this. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5ea6d9bc-4fd3-d8e6-adf4-513b4edc71e3>