Re: [PATCH] rcu: Fix missing TICK_DEP_MASK_RCU_EXP dependency check

[Joel Fernandes]

> On Jan 7, 2023, at 5:11 PM, Frederic Weisbecker <frederic@xxxxxxxxxx> wrote:
> 
> On Fri, Jan 06, 2023 at 07:01:28PM -0500, Joel Fernandes wrote:
>> (lost html content)

My problem is the iPhone wises up when I put a web link in an email. I want to look into smtp relays but then if I spent time on fixing that, I might not get time to learn from emails like these... 

> 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.

Ok.

> 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).

Makes sense. I think I was missing this use case and was going by the general design of exp grace periods.  I was incorrectly assuming the IPIs were being sent repeatedly for hold out CPUs, which is not the case I think. But that would another way to fix it?

But yeah I get your point, the first set of IPIs missed it, so we need the rescue-tick for long non-rcu_read_lock() implicit critical sections.. 

> 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().

Oh hmm, because that function is a NOOP for PREEMPT_COUNT=y and PREEMPT=n and will not report the deferred QS?  Maybe it should then. However I think the tick is still useful if after the preempt disabled section, will still did not exit the kernel.

We ought to start another Google doc on all of this if we have not yet…

Thanks!

 - Joel

> 
> Thanks.
> 
>