From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AF99C433F5 for ; Tue, 15 Feb 2022 17:32:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0BA96B007B; Tue, 15 Feb 2022 12:32:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BAE46B007D; Tue, 15 Feb 2022 12:32:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85D2F6B007E; Tue, 15 Feb 2022 12:32:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 754766B007B for ; Tue, 15 Feb 2022 12:32:19 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 358698249980 for ; Tue, 15 Feb 2022 17:32:19 +0000 (UTC) X-FDA: 79145707998.29.D2DCF4B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 6F06640004 for ; Tue, 15 Feb 2022 17:32:18 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8D1E4615DD; Tue, 15 Feb 2022 17:32:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F396CC340EB; Tue, 15 Feb 2022 17:32:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644946337; bh=dWJuGin0yny3G/JlamcHgjYAM9ls/bo33ms1my3RK4M=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=k2dValidg8ClDnhpDiX2/p01wd0zpBMbzPs5Txa4eWOEqT7fOJKth1KTMJtKLx9yE dIOmIpAlWrqTShTrFMi6s69hQUumFCjwxIA8gaaUZSpVeZO8O4R3FTMwoHLRb3T/AQ fdz/faCQ0N9ozaaKfTnjRyt7hMY8V7paVlHnN5jhdz1fn9P7Ihroa388jyElLdPDY5 foECbklDNLNqI8CMjfcofeHZP4DE2Xlc+CME/3oMbT3CgY+zn+9WvHsSedzmtiJ1jt WdHBa6g8ztDC2Q3DoDOuEsYRdHqKfB7vPa7cUTId9hPoL942V6kfCRjB55Jk/sPYdd NFWk9NQ+GI/LQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B55C25C0641; Tue, 15 Feb 2022 09:32:16 -0800 (PST) Date: Tue, 15 Feb 2022 09:32:16 -0800 From: "Paul E. McKenney" To: Nicolas Saenz Julienne Cc: Marcelo Tosatti , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, frederic@kernel.org, tglx@linutronix.de, mgorman@suse.de, linux-rt-users@vger.kernel.org, vbabka@suse.cz, cl@linux.com, willy@infradead.org Subject: Re: [PATCH 2/2] mm/page_alloc: Add remote draining support to per-cpu lists Message-ID: <20220215173216.GG4285@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20220208100750.1189808-1-nsaenzju@redhat.com> <20220208100750.1189808-3-nsaenzju@redhat.com> <2374bbca7651b671ec934fa5c630cbe3eed3b496.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2374bbca7651b671ec934fa5c630cbe3eed3b496.camel@redhat.com> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6F06640004 X-Stat-Signature: mfocozgn1ukcfqreojkfh3zkotz5uc6g X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=k2dValid; spf=pass (imf01.hostedemail.com: domain of "SRS0=I+/h=S6=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=I+/h=S6=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1644946338-964424 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 15, 2022 at 09:47:35AM +0100, Nicolas Saenz Julienne wrote: > On Tue, 2022-02-08 at 12:47 -0300, Marcelo Tosatti wrote: > > > Changes since RFC: > > > - Avoid unnecessary spin_lock_irqsave/restore() in free_pcppages_b= ulk() > > > - Add more detail to commit and code comments. > > > - Use synchronize_rcu() instead of synchronize_rcu_expedited(), th= e RCU > > > documentation says to avoid it unless really justified. I don't = think > > > it's justified here, if we can schedule and join works, waiting = for > > > an RCU grace period is OK. > >=20 > > https://patchwork.ozlabs.org/project/netdev/patch/1306228052.3026.16.= camel@edumazet-laptop/ > >=20 > > Adding 100ms to direct reclaim path might be problematic. It will als= o > > slowdown kcompactd (note it'll call drain_all_pages for each zone). >=20 > I did some measurements on an idle machine, worst case was ~30ms. I agr= ee that > might too much for direct reclaim, so I'll switch back to expedited and= add a > comment. Given your measurements, it looks to me like this is a case where use of expedited grace periods really is justified. For one thing, expedited grace periods are much less disruptive than they were in the old days, for example, back when they used stop-machine. For another thing, systems that cannot tolerate the disturbance (an IPI per non-idle non-nohz_full CPU per grace period, less than a wakeup) can always be booted with rcupdate.rcu_normal=3D1, which will make synchronize_rcu_expedited() act like synchronize_rcu(), at least once RCU has spawned its kthreads. And CONFIG_PREEMPT_RT=3Dy kernels forcibly set this mode. ;-) Nevertheless, expedited grace periods should not be used lightly because they do increase overhead. Thanx, Paul > > > - Avoid sparse warnings by using rcu_access_pointer() and > > > rcu_dereference_protected(). > > >=20 > > > include/linux/mmzone.h | 22 +++++- > > > mm/page_alloc.c | 155 ++++++++++++++++++++++++++-----------= ---- > > > mm/vmstat.c | 6 +- > > > 3 files changed, 120 insertions(+), 63 deletions(-) > > >=20 > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > > index b4cb85d9c6e8..b0b593fd8e48 100644 > > > --- a/include/linux/mmzone.h > > > +++ b/include/linux/mmzone.h > > > @@ -388,13 +388,31 @@ struct per_cpu_pages { > > > short expire; /* When 0, remote pagesets are drained */ > > > #endif > > > =20 > > > - struct pcplists *lp; > > > + /* > > > + * As a rule of thumb, any access to struct per_cpu_pages's 'lp' = has > > > + * happen with the pagesets local_lock held and using > > > + * rcu_dereference_check(). If there is a need to modify both > > > + * 'lp->count' and 'lp->lists' in the same critical section 'pcp-= >lp' > > > + * can only be derefrenced once. See for example: > >=20 > > Typo. >=20 > Noted. >=20 > Thanks! >=20 > --=20 > Nicol=E1s S=E1enz >=20