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 49FC0C197A0 for ; Tue, 21 Nov 2023 00:38:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A81506B035E; Mon, 20 Nov 2023 19:38:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A0A716B036E; Mon, 20 Nov 2023 19:38:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AA866B0374; Mon, 20 Nov 2023 19:38:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 772E36B035E for ; Mon, 20 Nov 2023 19:38:14 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3E521C0B49 for ; Tue, 21 Nov 2023 00:38:14 +0000 (UTC) X-FDA: 81480099708.23.A014E24 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 76FA1180013 for ; Tue, 21 Nov 2023 00:38:12 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NEAPL1v4; spf=pass (imf06.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"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700527092; 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=m3+mV4D9cHsYIpdu5rD5+dCdp87Lbcn/lIoF5cFH4mg=; b=lzKx1ZIAIK8qbLfLBFMqxHlBuCH0bjpB0pN5ljvB+JaxsIlxuTIdBetOZBeiAzP+tLMaF5 FZTCaVsVwuCyjlmN4kc9Zd2PqyhpjGlzV840Gyv/JHEcmz0BcDqt/rHd58NpHMTO/33BuT moEnIAw3G3/GQuKx15SZFDzCYVGYZAw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700527092; a=rsa-sha256; cv=none; b=mTWi9vkt2aDN3Vw1Ib+dzbxYWYZBYuNIU+F2kn8cuOpxEXNgy/vcERGCeRgrL7YQlzm0+/ M3+6hnKMqR0qX9pbMiV/cg295nb4M/JRt56rxjhSLMZVLzkjOUKR5CgLF6EL1uItaXUDDz 7HK+1tMzA/CycsLTxIjB9p9Hw9nTBiU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NEAPL1v4; spf=pass (imf06.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"; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4AB4D615D9; Tue, 21 Nov 2023 00:38:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D90E3C433C8; Tue, 21 Nov 2023 00:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700527090; bh=YaadEINN+MJ2ly7Vsrgyw8WtUuyHp41LyZ7pnHSZI7I=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=NEAPL1v4B1fGEyzm8CG5AD4iy/ZOD+hVeCbdkf6bmBFbows0o2JfcguPGkxq2XmbM xa87Px1CI28arzhCoGmlzLXrYU3yu056Ey6CBNEyNS7u80d29qycuiwrq9WOCBVkD9 RvhbZhkt4jqpOw5rztsyAmrHhpKYYfvf3xM8LWutEdQDzOQdZQ06QyDM/TddnfHx6F +yX9ZnHVLcx8FayNLGuIvJ1hELFL4ilgQdyinsueEhXLpyat4C5P7mC7YTGM7S615x tDDfWvMW054oKg63e9QiETGJ7UKrBC3oYW0Y2gUEE1I1on4TOIELxtcE+TFGOPGyDU SeTDogLBJfz1A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 787C7CE1390; Mon, 20 Nov 2023 16:38:10 -0800 (PST) Date: Mon, 20 Nov 2023 16:38:10 -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: <2027da00-273d-41cf-b9e7-460776181083@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107215742.363031-49-ankur.a.arora@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231107215742.363031-49-ankur.a.arora@oracle.com> X-Rspamd-Queue-Id: 76FA1180013 X-Rspam-User: X-Stat-Signature: qmd3z4p5fjxcrfkb4y8n6idcpbkk4yaz X-Rspamd-Server: rspam03 X-HE-Tag: 1700527092-746499 X-HE-Meta: U2FsdGVkX1/GVPj95EnK8nwLvbsjBQeg9pvHFpTD7jtoVE0UsLQXbt3s+ekMFhm60Wf12y8L7yvSNj+KbEyn7vCiq/nO8+MZCTBeFa7VhEEnN0n3JnooBphjTKwku6n+4XIduQob6FuoCU3T3nTi+yc2iTctwgpIQZ6krmEnSoHJutFfS4nPjUvR6lW74IFSFxTcBxgkQCWmo/ildooSnaSh9jYFzS+BXApiXieTLOMrHFGxLKe1Wwz8eQ/WVJg9DMfv5+gbQcgtaSebzJzZqA4ZQZja2LYmDzJnGpg6OCNx4ecPJYL03JFVFLxPDZ+AkoWafWY7wGnykKr7t2b5P11hm+0Lb9lm/mMHT38K8iR/tGxXtlURWaeHnM4nM3ktXDsbBm3RrWFQwYe/rCgAkoe/IyyQS7+GpUmBDXLQWgtXoFAPSXaMMCe7qNLwIcyc4DQqcdhP2Smftz2YNPCS7K1xC7cs67CGVrJuH2E6f8sUIPWoLlopqqq0jGmg8S0JkJNu4ltWOTz7lo/QCm498t4dHqIoR17GzYO9b0IQ6y+HRzT0Dt6YafLpvodWLQOsFEfin5R507G6+r43KlF2pP6oPsSYtFX+7DEyghk5xgH3Yxdi3ZqLtXPdCW+jjRPSkblnI1Na609WttF3meMo9u8y8HeIPaWzkRbYB0mi62dt5plRdH6lAeyD6llGARuWNqZLPQrRrmOokpWoaNX5QbliNRnLz9kQlXrcXRuetx76nkXP6GADDJVJjlDYeXNwnYqSnjD4H9fQi72LAvl/mmcDcbcsuXn8otrbLkOcmWCGbQb7WyhG6alVradByxLV7bmFhslPwlqzBQ6QBF4zo9yOhSPg/aFEEY2+Gm7HfYCfyua6xRkR9lRccjy5M+njUGxBL9futH5EjaFOh1bYsJ3wNjjWR/3ZR4QUBlvs8GMnPtog0OrAAEVAoDAu8L/FBHEULJu+zwnh0l57g4X JbM4UOXQ T0g59EbuKzbaXn4yvs0Fp9GKiFbtXS4hVWhr/w1p4gbVc627rLwUYJ0rydNd7FKfvzdUhLFX45tP2bbgUHYMFZbmti4Lq3RUm3STshk47WcHBu9LH1kn/Mdk2sjrf1t8PruxpwuhdmJ4mmlAIRfT+ZBADMM4Qwr+LS4yl+Smfl27IBTOTsUuSXYkVAMP6wLfpT5Nm4ScjHzayh1YCCk+gLpfC3ZeZ0jBMZreJneOV/4bANJgB+5l+W+CJXlya7/9PZZPolI9pauE+p7Ri2ehju0MKKqNX2u1djeD74MshJTDO8Unqpq9ufqJb6tAP7eYWXYXdyD8v+cki0aCIXbbz0eYnkr4nY7FSWhivNSVFUZTj459gdxDhxti3LosVfO1ZydjC7gHl7h1xOokiN/BonF+IQviez0jf3oF2PB5OgwwhAoTbHP5qbMNPQFO/TnOxHwCWhfTJ3MGqgyx5IU7efBVNEdWCmNII+xn5iRXmJ54boyoDyfiuvhSgLW5FvCa9GHipsm4DgLlOUsALPph2cVtj9jCFyxGI729F53xQ6XIRWszqP7jGuine7IlwzhhLxMwjHzjWryxwwgbqq/piRsBhiM1JI9W2oSDKVWXD/ZTNkNbGcD7vRlVAcwC0l0stqSe0/HveM2FjqjS1y+ZSG5xSEhOw5/a+FPgD 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 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. Or did I miss a change that causes preempt_enable() to help RCU out? Thanx, Paul > return 0; > } > EXPORT_SYMBOL(_cond_resched); > -- > 2.31.1 >