All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	tglx@linutronix.de, paulmck@kernel.org, mingo@kernel.org,
	bigeasy@linutronix.de, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	vschneid@redhat.com, efault@gmx.de, sshegde@linux.ibm.com,
	boris.ostrovsky@oracle.com,
	Daniel Bristot de Oliveira <bristot@kernel.org>
Subject: Re: [PATCH v2 5/6] osnoise: handle quiescent states for PREEMPT_RCU=n, PREEMPTION=y
Date: Fri, 29 Nov 2024 15:22:12 +0100	[thread overview]
Message-ID: <Z0nOFDt_Y370pyew@localhost.localdomain> (raw)
In-Reply-To: <87seraeimb.fsf@oracle.com>

Le Thu, Nov 28, 2024 at 09:03:56PM -0800, Ankur Arora a écrit :
> 
> Frederic Weisbecker <frederic@kernel.org> writes:
> 
> > Le Wed, Nov 06, 2024 at 12:17: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. And, for PREEMPT_RCU=y configurations does this
> >> by directly calling rcu_momentary_eqs().
> >>
> >> With PREEMPT_LAZY=y, however, we can have configurations with
> >> (PREEMPTION=y, PREEMPT_RCU=n), which means neither of the above
> >> can help.
> >>
> >> Handle that by fallback to the explicit quiescent states via
> >> rcu_momentary_eqs().
> >>
> >> Cc: Paul E. McKenney <paulmck@kernel.org>
> >> Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
> >> Cc: Steven Rostedt <rostedt@goodmis.org>
> >> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> >> Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
> >> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> >> ---
> >>  kernel/trace/trace_osnoise.c | 22 ++++++++++++----------
> >>  1 file changed, 12 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> >> index a50ed23bee77..15e9600d231d 100644
> >> --- a/kernel/trace/trace_osnoise.c
> >> +++ b/kernel/trace/trace_osnoise.c
> >> @@ -1538,18 +1538,20 @@ static int run_osnoise(void)
> >>  		/*
> >>  		 * In some cases, notably when running on a nohz_full CPU with
> >>  		 * a stopped tick PREEMPT_RCU has no way to account for QSs.
> >> -		 * This will eventually cause unwarranted noise as PREEMPT_RCU
> >> -		 * will force preemption as the means of ending the current
> >> -		 * grace period. We avoid this problem by calling
> >> -		 * rcu_momentary_eqs(), which performs a zero duration
> >> -		 * EQS allowing PREEMPT_RCU to end the current grace period.
> >> -		 * This call shouldn't be wrapped inside an RCU critical
> >> -		 * section.
> >> +		 * This will eventually cause unwarranted noise as RCU forces
> >> +		 * preemption as the means of ending the current grace period.
> >> +		 * We avoid this by calling rcu_momentary_eqs(), which performs
> >> +		 * a zero duration EQS allowing RCU to end the current grace
> >> +		 * period. This call shouldn't be wrapped inside an RCU
> >> +		 * critical section.
> >>  		 *
> >> -		 * Note that in non PREEMPT_RCU kernels QSs are handled through
> >> -		 * cond_resched()
> >> +		 * For non-PREEMPT_RCU kernels with cond_resched() (non-
> >> +		 * PREEMPT_LAZY configurations), QSs are handled through
> >> +		 * cond_resched(). For PREEMPT_LAZY kernels, we fallback to
> >> +		 * the zero duration QS via rcu_momentary_eqs().
> >>  		 */
> >> -		if (IS_ENABLED(CONFIG_PREEMPT_RCU)) {
> >> +		if (IS_ENABLED(CONFIG_PREEMPT_RCU) ||
> >> +		    (!IS_ENABLED(CONFIG_PREEMPT_RCU) && IS_ENABLED(CONFIG_PREEMPTION))) {
> >>  			if (!disable_irq)
> >>  				local_irq_disable();
> >
> > How about making this unconditional so it works everywhere and doesn't
> > rely on cond_resched() Kconfig/preempt-dynamic mood?
> 
> I think it's a minor matter given that this isn't a hot path, but
> we don't really need it for the !PREEMPT_RCU configuration.

Well if you make it unconditional, cond_resched() / rcu_all_qs() won't do its
own rcu_momentary_qs(), because rcu_data.rcu_urgent_qs should
be false. So that essentially unify the behaviours for all configurations.

Thanks.

> 
> Still, given that both of those clauses imply CONFIG_PREEMPTION, we
> can just simplify this to (with an appropriately adjusted comment):
> 
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
> @@ -1543,7 +1543,7 @@ static int run_osnoise(void)
>                  * Note that in non PREEMPT_RCU kernels QSs are handled through
>                  * cond_resched()
>                  */
> -               if (IS_ENABLED(CONFIG_PREEMPT_RCU)) {
> +               if (IS_ENABLED(CONFIG_PREEMPTION)) {
>                         if (!disable_irq)
>                                 local_irq_disable();
> 
> --
> ankur

  reply	other threads:[~2024-11-29 14:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 20:17 [PATCH v2 0/6] RCU changes for PREEMPT_LAZY Ankur Arora
2024-11-06 20:17 ` [PATCH v2 1/6] rcu: fix header guard for rcu_all_qs() Ankur Arora
2024-11-13 14:50   ` Frederic Weisbecker
2024-11-14  7:06   ` Sebastian Andrzej Siewior
2024-11-15  4:55     ` Ankur Arora
2024-11-06 20:17 ` [PATCH v2 2/6] rcu: rename PREEMPT_AUTO to PREEMPT_LAZY Ankur Arora
2024-11-13 14:59   ` Frederic Weisbecker
2024-11-13 23:51     ` Ankur Arora
2024-11-14  7:07   ` Sebastian Andrzej Siewior
2024-11-06 20:17 ` [PATCH v2 3/6] rcu: limit PREEMPT_RCU configurations Ankur Arora
2024-11-13 15:31   ` Frederic Weisbecker
2024-11-14  0:23     ` Ankur Arora
2024-11-14  8:25       ` Sebastian Andrzej Siewior
2024-11-14 11:36         ` Frederic Weisbecker
2024-11-25 21:40     ` Ankur Arora
2024-11-26 14:49       ` Frederic Weisbecker
2024-11-27  5:35         ` Ankur Arora
2024-11-27  6:19           ` Ankur Arora
2024-11-28 12:33             ` Frederic Weisbecker
2024-11-29  4:39               ` Ankur Arora
2024-11-29 12:49                 ` Frederic Weisbecker
2024-11-06 20:17 ` [PATCH v2 4/6] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y Ankur Arora
2024-11-14  8:50   ` Sebastian Andrzej Siewior
2024-11-15  4:58     ` Ankur Arora
2024-11-28 13:36   ` Frederic Weisbecker
2024-11-06 20:17 ` [PATCH v2 5/6] osnoise: handle quiescent states for PREEMPT_RCU=n, PREEMPTION=y Ankur Arora
2024-11-14  9:22   ` Sebastian Andrzej Siewior
2024-11-15  4:59     ` Ankur Arora
2024-11-28 14:33   ` Frederic Weisbecker
2024-11-29  5:03     ` Ankur Arora
2024-11-29 14:22       ` Frederic Weisbecker [this message]
2024-11-29 19:21         ` Ankur Arora
2024-11-06 20:17 ` [PATCH v2 6/6] sched: warn for high latency with TIF_NEED_RESCHED_LAZY Ankur Arora
2024-11-14  9:16   ` Sebastian Andrzej Siewior
2024-11-14 10:01 ` [PATCH v2 0/6] RCU changes for PREEMPT_LAZY Sebastian Andrzej Siewior
2024-11-15  5:20   ` Ankur Arora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z0nOFDt_Y370pyew@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=bigeasy@linutronix.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bristot@kernel.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=efault@gmx.de \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.