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
Subject: Re: [PATCH v2 4/6] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y
Date: Thu, 28 Nov 2024 14:36:31 +0100	[thread overview]
Message-ID: <Z0hx34Cjw1X0r1lo@localhost.localdomain> (raw)
In-Reply-To: <20241106201758.428310-5-ankur.a.arora@oracle.com>

Le Wed, Nov 06, 2024 at 12:17:56PM -0800, Ankur Arora a écrit :
> With PREEMPT_RCU=n, cond_resched() provides urgently needed quiescent
> states for read-side critical sections via rcu_all_qs().
> One reason why this was needed, was lacking preempt-count, the tick
> handler has no way of knowing whether it is executing in a read-side
> critical section or not.
> 
> With PREEMPT_LAZY=y, there can be configurations with PREEMPT_COUNT=y,
> PREEMPT_RCU=n, where cond_resched() is a stub that does not provide
> quiescent states via rcu_all_qs().
> 
> So, use the availability of preempt_count() to report quiescent states
> in rcu_flavor_sched_clock_irq().
> 
> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> ---
>  kernel/rcu/tree_plugin.h | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 1c7cbd145d5e..da324d66034b 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -974,13 +974,16 @@ 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() ||
> +	     (IS_ENABLED(CONFIG_PREEMPT_COUNT) &&
> +	      !(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK)))) {

I'm never sure if nested hardirqs are still possible but just in case,

    preempt_count() == HARDIRQ_OFFSET

might be a more robust check. And that also applies to the PREEMPT_RCU
implementation.

Thanks.

>  
>  		/*
>  		 * Get here if this CPU took its interrupt from user
> -		 * mode or from the idle loop, and if this is not a
> -		 * nested interrupt.  In this case, the CPU is in
> -		 * a quiescent state, so note it.
> +		 * mode, from the idle loop without this being a nested
> +		 * interrupt, or while not holding a preempt count (but
> +		 * with PREEMPT_COUNT=y. In this case, the CPU is in a
> +		 * quiescent state, so note it.
>  		 *
>  		 * No memory barrier is required here because rcu_qs()
>  		 * references only CPU-local variables that other CPUs
> -- 
> 2.43.5
> 

  parent reply	other threads:[~2024-11-28 13:36 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 [this message]
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
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=Z0hx34Cjw1X0r1lo@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=bigeasy@linutronix.de \
    --cc=boris.ostrovsky@oracle.com \
    --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.