All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: paulmck@kernel.org, Zqiang <qiang1.zhang@intel.com>,
	quic_neeraju@quicinc.com, rcu@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: Fix missing TICK_DEP_MASK_RCU_EXP dependency check
Date: Sat, 7 Jan 2023 23:11:34 +0100	[thread overview]
Message-ID: <Y7nuFrJ3gjNzXmCz@lothringen> (raw)
In-Reply-To: <344A2A3B-628E-467C-BBDF-11C3AB63D432@joelfernandes.org>

On Fri, Jan 06, 2023 at 07:01:28PM -0500, Joel Fernandes wrote:
> (lost html content)

I can't find a place where the exp grace period sends an IPI to
CPUs slow to report a QS. But anyway you really need the tick to poll
periodically on the CPU to chase a quiescent state.

Now arguably it's probably only useful when CONFIG_PREEMPT_COUNT=y
and rcu_exp_handler() has interrupted a preempt-disabled or bh-disabled
section. Although rcu_exp_handler() sets TIF_RESCHED, which is handled
by preempt_enable() and local_bh_enable() when CONFIG_PREEMPT=y.
So probably it's only useful when CONFIG_PREEMPT_COUNT=y and CONFIG_PREEMPT=n
(and there is also PREEMPT_DYNAMIC to consider).

If CONFIG_PREEMPT_COUNT=n, the tick can only report idle and user
as QS, but those are already reported explicitly on ct_kernel_exit() ->
rcu_preempt_deferred_qs().

Thanks.



  parent reply	other threads:[~2023-01-07 22:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20 14:16 [PATCH] rcu: Fix missing TICK_DEP_MASK_RCU_EXP dependency check Zqiang
2022-12-21 20:16 ` Paul E. McKenney
2023-01-07 21:39   ` Frederic Weisbecker
2023-01-09 19:28     ` Paul E. McKenney
     [not found]   ` <344A2A3B-628E-467C-BBDF-11C3AB63D432@joelfernandes.org>
2023-01-07 22:11     ` Frederic Weisbecker [this message]
2023-01-08  2:48       ` Joel Fernandes
2023-01-08  2:55         ` Joel Fernandes
2023-01-08 23:09           ` Frederic Weisbecker
2023-01-09 19:32             ` Paul E. McKenney
2023-01-09 23:55               ` Frederic Weisbecker
2023-01-13 19:25                 ` Paul E. McKenney

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=Y7nuFrJ3gjNzXmCz@lothringen \
    --to=frederic@kernel.org \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=qiang1.zhang@intel.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    /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.