[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z1xGAYQbn4yKy3MC@localhost.localdomain>
Date: Fri, 13 Dec 2024 15:34:41 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org, tglx@...utronix.de,
paulmck@...nel.org, mingo@...nel.org, bigeasy@...utronix.de,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, efault@....de,
sshegde@...ux.ibm.com, boris.ostrovsky@...cle.com,
Daniel Bristot de Oliveira <bristot@...nel.org>
Subject: Re: [PATCH v3 6/7] osnoise: provide quiescent states
Le Thu, Dec 12, 2024 at 08:06:57PM -0800, Ankur Arora a écrit :
> To reduce RCU noise for nohz_full configurations, osnoise depends
> on cond_resched() providing quiescent states for PREEMPT_RCU=n
> configurations. For PREEMPT_RCU=y configurations -- where
> cond_resched() is a stub -- we do this by directly calling
> rcu_momentary_eqs().
>
> With (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), however, we have a
> configuration with (PREEMPTION=y, PREEMPT_RCU=n) where neither
> of the above can help.
>
> Handle that by providing an explicit quiescent state here for all
> configurations.
>
> As mentioned above this is not needed for non-stubbed cond_resched(),
> but, providing a quiescent state here just pulls in one that a future
> cond_resched() would provide, so doesn't cause any extra work for
> this configuration.
>
> Cc: Paul E. McKenney <paulmck@...nel.org>
> Cc: Daniel Bristot de Oliveira <bristot@...nel.org>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Suggested-by: Paul E. McKenney <paulmck@...nel.org>
> Acked-by: Daniel Bristot de Oliveira <bristot@...nel.org>
> Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
Reviewed-by: Frederic Weisbecker <frederic@...nel.org>
Powered by blists - more mailing lists