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 C7D19C5ACB3 for ; Tue, 21 Nov 2023 05:34:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 489CF6B0391; Tue, 21 Nov 2023 00:34:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 439C36B03D2; Tue, 21 Nov 2023 00:34:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 301406B03D3; Tue, 21 Nov 2023 00:34:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 20BEF6B0391 for ; Tue, 21 Nov 2023 00:34:09 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CEA7C40831 for ; Tue, 21 Nov 2023 05:34:08 +0000 (UTC) X-FDA: 81480845376.28.77E051A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 0C2F9140013 for ; Tue, 21 Nov 2023 05:34:06 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fcwM7FTw; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700544847; a=rsa-sha256; cv=none; b=4pgagxClnFbIbXErb94LKvs9qvJVgG58+8v9GfpmNui9ix/zZcuaFHipjkQh+gOfY47A7A sObcNy3SG4qtKhW2EAf9hY20rMCtJNPRX+JQlkmzx6aBdnnful01tg1fjQq/p/Y4oUcyeQ dZi3N4VuySq3HeNzpx5LMOIZss1EC+Y= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fcwM7FTw; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700544847; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0ZMgO9JBF6XB/gaFuOgWZHkFFoiXzGcrDAY8/h93Y9g=; b=oLRltLBJz/6bZEvUvw63AojTnh0UxfG1KGg5RGCqVittlzCi1IQqcHmi8lykZqAuy4P0Jo NVyFrrwVqm2hTr0mfuzTW/PugskfED3ZpSqyTs2XNfuF0TAh7Sc0qbsVDQaAwaY1C8E2PX 2Qyu0qcDsh6w8Hj7HhgJ+JIxyMVhPuE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EF52061699; Tue, 21 Nov 2023 05:34:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8874CC433C7; Tue, 21 Nov 2023 05:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700544845; bh=g1nddYWdvtbO7s/fVVFG5d5bDrBXCAtwPfQhYHXvpz4=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=fcwM7FTw7uPaNAVjuxsF0odl0g0PoUaOqd6mSORNmGgjvgXZx9N1qJNP1wD0w4HO3 CB7oIAvVz27vaHk/atReCzpRZ6tqf0z6yaz2rNKdUQ2g3SE33TDY4t/r7JdE2dcHNm ej2r35c5nJ5AHrl8ZASoVuMMhT1hbJoB+PLAmQWjymmZSOijCiOU4ns0gkwP35huk+ 0oNDC20SfSDppIJqhj9hIEqNJ68auKU6NOOCR4wBPjcHkE03B6OKjJ7SoHmQRt15+q o8nv6UqSttzOYqDYxwzgrgxfFBTOWQlNmtpa9USiqr5AaOyAb8gkE6P+1amusNMQx+ PlKrW7U0h+agA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 12A83CE1390; Mon, 20 Nov 2023 21:34:05 -0800 (PST) Date: Mon, 20 Nov 2023 21:34:05 -0800 From: "Paul E. McKenney" To: Ankur Arora Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com Subject: Re: [RFC PATCH 48/86] rcu: handle quiescent states for PREEMPT_RCU=n Message-ID: <31d50051-e42c-4ef2-a1ac-e45370c3752e@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107215742.363031-49-ankur.a.arora@oracle.com> <2027da00-273d-41cf-b9e7-460776181083@paulmck-laptop> <87lear4wj6.fsf@oracle.com> <46a4c47a-ba1c-4776-a6f8-6c2146cbdd0d@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46a4c47a-ba1c-4776-a6f8-6c2146cbdd0d@paulmck-laptop> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0C2F9140013 X-Stat-Signature: 7yesfdsea8fwnqg4yuorccb4sh4freyb X-HE-Tag: 1700544846-511493 X-HE-Meta: U2FsdGVkX1+zPunq2iuPYicH14sArU0y9cUY7Wuzn3lpjcSM+xysd3cn13kIFBUxF0fVypSCko3xblTG+VXe0RAWyf73FDDDYTbBKpH6HVl9GFdxrgWFXP9PnvZQCZUOF6c5P1n8+ap+pkKWCpl1UfBj37eO0FxfcKfYPM5CksQIoR75adVJxaGxuLI8jHmEsW7B1MgNGqtOLIeMXvSVWwqjPpnIa5nykNm9lajKVaXHEKVDO6E0Hex8rB+UI24wKmeWYl1xiVGmfFW0fRDYhj6arjsPxNoZaE5YuJw177xGApc/r7gC5y9I2T2yd95vL8DlSql34H+HUSPqbdeNMnNNrwIADZ0+xHDH/lIKZUThVE8/+JxVsuSkUmDseDMCGYcgiP7ANO5GRieuPozxrw8t7Fb0oatccN8TyE/9CdpHok5IZV3Ih0fnh/2DjCud2r9v0feY4mF4Tu3UwPQKxFbHxPHLZMikDGD89X3W2Q21koURdya9ajkeXZwau8dC4r7mo5hdpvD3END8f6tAYJ70K5o+SEgAtk71p3b62G3P1tkjq8dbPQc8EN6Ar5XVqlIWTj5Ev0JKJnwS7AeFXGJH5bhtuajdtiqeqLSn5XcS2qs+4IodRxDHxUGlL34VZ7beEnR7r9pNH8JgvrFgu4D9I6Iu/shOGQKiusalJcX3sBhg6LIKgQNqmjiBbhkPncJ6tU7kDxFKvDfA5R8KEJWRuQnqFiytFYYMScs0HMDj18sx8MFoAkvsBHFxYUlBCp3vPwbsdFTK9N8y0RX8LekVVZ9i8gZrJSD9zJimjaIZFmlo462fmlfWfI0LbndIlbFwHQv+YgHCWflktmQZH1fIehQ4Npn4rPbFEKzWhlhIVhVCZMjY8kzCgrUuNft7QMA3a+tDYPD5CJLm4361HKTSWavlYMNH9KAmGthvVUSh8Fvvk3bcTTGAoyPZgl9AcIz9bLFljQ6BY4D4Ccs B89arOgl tA4xim51DqPfDCQOWzJaoka6SYEV+2iOeO091iIipeDqn69Jefgl3cqOLDirfMVVH5mD2KEI+bKIQ5s7kPdhQNKmX3JQGv0WwTIbPFlYRAVS5rkkqA2y9Dh6DW9eOE0v+LH/5fm0uXy31Ae29YuW1IoNIl1mtYmw/waZ4WiTt+z5wB/Axpc1h83pjK6Z90C7TXrW2TWBNkEuvU3H8caihf7zATVSJOeC8PLKRO51BP6EsKnQyxW1aVaHK0OOVeFBrJXidIg+zkBEcdXyHH2PHx0QNnELl3f6XvYTfT7gKQ6YMSs60+OXmqX1SS+kiFtZbSeqEQfXtUHaZeWLNNbJN82gAkSoOGeH9yVMTA/o0X2igmJ/hdXONypUD6nQVT+Vng+EcklSlItZsM19I0RI+iFJEclEZa8v3H1SBQ1Cmriupb2X5dfK9FFPyFHtFtsNsjwLvb1ShhyVR7cVJmFyCNxcX8oVYshW8eOzcWnpwzOJiM3dtjGXSlsW01UR4DTjNkXdixt8BSVQ64U46g13N2yWSeQ7VMEnsavPgf/we+VAojh2RmMW8jYq1cozBn+aGgkvg33sbFbNn3Yo67us+hHPwizAVCdiBUnQfMIi7tjMCYRPZQUsz55+jb/yGhbl8Y4ab7UloNuNeFBuujJh6np2xiv6ck9c76zxT 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: List-Subscribe: List-Unsubscribe: On Mon, Nov 20, 2023 at 09:17:57PM -0800, Paul E. McKenney wrote: > On Mon, Nov 20, 2023 at 07:26:05PM -0800, Ankur Arora wrote: > > > > Paul E. McKenney writes: > > > On Tue, Nov 07, 2023 at 01:57:34PM -0800, Ankur Arora wrote: > > >> cond_resched() is used to provide urgent quiescent states for > > >> read-side critical sections on PREEMPT_RCU=n configurations. > > >> This was necessary because lacking preempt_count, there was no > > >> way for the tick handler to know if we were executing in RCU > > >> read-side critical section or not. > > >> > > >> An always-on CONFIG_PREEMPT_COUNT, however, allows the tick to > > >> reliably report quiescent states. > > >> > > >> Accordingly, evaluate preempt_count() based quiescence in > > >> rcu_flavor_sched_clock_irq(). > > >> > > >> Suggested-by: Paul E. McKenney > > >> Signed-off-by: Ankur Arora > > >> --- > > >> kernel/rcu/tree_plugin.h | 3 ++- > > >> kernel/sched/core.c | 15 +-------------- > > >> 2 files changed, 3 insertions(+), 15 deletions(-) > > >> > > >> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > >> index f87191e008ff..618f055f8028 100644 > > >> --- a/kernel/rcu/tree_plugin.h > > >> +++ b/kernel/rcu/tree_plugin.h > > >> @@ -963,7 +963,8 @@ static void rcu_preempt_check_blocked_tasks(struct rcu_node *rnp) > > >> */ > > >> static void rcu_flavor_sched_clock_irq(int user) > > >> { > > >> - if (user || rcu_is_cpu_rrupt_from_idle()) { > > >> + if (user || rcu_is_cpu_rrupt_from_idle() || > > >> + !(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK))) { > > > > > > This looks good. > > > > > >> /* > > >> * Get here if this CPU took its interrupt from user > > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > >> index bf5df2b866df..15db5fb7acc7 100644 > > >> --- a/kernel/sched/core.c > > >> +++ b/kernel/sched/core.c > > >> @@ -8588,20 +8588,7 @@ int __sched _cond_resched(void) > > >> preempt_schedule_common(); > > >> return 1; > > >> } > > >> - /* > > >> - * In preemptible kernels, ->rcu_read_lock_nesting tells the tick > > >> - * whether the current CPU is in an RCU read-side critical section, > > >> - * so the tick can report quiescent states even for CPUs looping > > >> - * in kernel context. In contrast, in non-preemptible kernels, > > >> - * RCU readers leave no in-memory hints, which means that CPU-bound > > >> - * processes executing in kernel context might never report an > > >> - * RCU quiescent state. Therefore, the following code causes > > >> - * cond_resched() to report a quiescent state, but only when RCU > > >> - * is in urgent need of one. > > >> - * / > > >> -#ifndef CONFIG_PREEMPT_RCU > > >> - rcu_all_qs(); > > >> -#endif > > > > > > But... > > > > > > Suppose we have a long-running loop in the kernel that regularly > > > enables preemption, but only momentarily. Then the added > > > rcu_flavor_sched_clock_irq() check would almost always fail, making > > > for extremely long grace periods. > > > > So, my thinking was that if RCU wants to end a grace period, it would > > force a context switch by setting TIF_NEED_RESCHED (and as patch 38 mentions > > RCU always uses the the eager version) causing __schedule() to call > > rcu_note_context_switch(). > > That's similar to the preempt_schedule_common() case in the > > _cond_resched() above. > > But that requires IPIing that CPU, correct? > > > But if I see your point, RCU might just want to register a quiescent > > state and for this long-running loop rcu_flavor_sched_clock_irq() does > > seem to fall down. > > > > > Or did I miss a change that causes preempt_enable() to help RCU out? > > > > Something like this? > > > > diff --git a/include/linux/preempt.h b/include/linux/preempt.h > > index dc5125b9c36b..e50f358f1548 100644 > > --- a/include/linux/preempt.h > > +++ b/include/linux/preempt.h > > @@ -222,6 +222,8 @@ do { \ > > barrier(); \ > > if (unlikely(preempt_count_dec_and_test())) \ > > __preempt_schedule(); \ > > + if (!(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK))) \ > > + rcu_all_qs(); \ > > } while (0) > > Or maybe something like this to lighten the load a bit: > > #define preempt_enable() \ > do { \ > barrier(); \ > if (unlikely(preempt_count_dec_and_test())) { \ > __preempt_schedule(); \ > if (raw_cpu_read(rcu_data.rcu_urgent_qs) && \ > !(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK))) \ > rcu_all_qs(); \ > } \ > } while (0) > > And at that point, we should be able to drop the PREEMPT_MASK, not > that it makes any difference that I am aware of: > > #define preempt_enable() \ > do { \ > barrier(); \ > if (unlikely(preempt_count_dec_and_test())) { \ > __preempt_schedule(); \ > if (raw_cpu_read(rcu_data.rcu_urgent_qs) && \ > !(preempt_count() & SOFTIRQ_MASK)) \ > rcu_all_qs(); \ > } \ > } while (0) > > Except that we can migrate as soon as that preempt_count_dec_and_test() > returns. And that rcu_all_qs() disables and re-enables preemption, > which will result in undesired recursion. Sigh. > > So maybe something like this: > > #define preempt_enable() \ > do { \ > if (raw_cpu_read(rcu_data.rcu_urgent_qs) && \ > !(preempt_count() & SOFTIRQ_MASK)) \ Sigh. This needs to include (PREEMPT_MASK | SOFTIRQ_MASK), but check for equality to something like (1UL << PREEMPT_SHIFT). Clearly time to sleep. :-/ Thanx, Paul > rcu_all_qs(); \ > barrier(); \ > if (unlikely(preempt_count_dec_and_test())) { \ > __preempt_schedule(); \ > } \ > } while (0) > > Then rcu_all_qs() becomes something like this: > > void rcu_all_qs(void) > { > unsigned long flags; > > /* Load rcu_urgent_qs before other flags. */ > if (!smp_load_acquire(this_cpu_ptr(&rcu_data.rcu_urgent_qs))) > return; > this_cpu_write(rcu_data.rcu_urgent_qs, false); > if (unlikely(raw_cpu_read(rcu_data.rcu_need_heavy_qs))) { > local_irq_save(flags); > rcu_momentary_dyntick_idle(); > local_irq_restore(flags); > } > rcu_qs(); > } > EXPORT_SYMBOL_GPL(rcu_all_qs); > > > Though I do wonder about the likelihood of hitting the case you describe > > and maybe instead of adding the check on every preempt_enable() > > it might be better to instead force a context switch in the > > rcu_flavor_sched_clock_irq() (as we do in the PREEMPT_RCU=y case.) > > Maybe. But rcu_all_qs() is way lighter weight than a context switch. > > Thanx, Paul