[attn: Steve] Re: Normal RCU grace period can be stalled for long because need-resched flags not set?

[Joel Fernandes <joel@joelfernandes.org>]

On Thu, Jul 04, 2019 at 06:57:26PM -0700, Paul E. McKenney wrote:
[snip]
> > I tried again, if I make sure the ftrace dump absolutely does not happen
> > until the preempt-disable loop is done marked by a new global variable as you
> > pointed, then it fixes it. And I don't need any set_preempt_need_resched() or
> > rcu_perf_shutdown_wait() in my preempt disable loop to fix it. Basically the
> > below diff. However, it still does answer the question about why a parallel
> > ftrace dump running in parallel with the still running preempt-disable loop
> > caused some writers to have multi-second grace periods. I think something
> > during the ftrace dump prevented the tick path of that loop CPU to set the
> > need-resched flag. It is quite hard to trace because the problem itself is
> > caused by tracing, so by the time the dump starts, the traces cannot be seen
> > after that which are what would give a clue here.
> 
> Hmmm...  Doesn't ftrace_dump() iterate through the trace buffer with
> interrupts disabled or some such?  If so, that would fully explain
> its delaying RCU grace periods.

Looking through the ftrace_dump() code, I don't see any interrupt disabled
happening, and in this case it would be happening on a different CPU than my
preempt disable loop anyway since that loop runs on a CPU I reserved, and the
writer thread doing the dump runs on a different CPU. So it is a bit odd that
the presence of my preempt disable loop effects anything. No having the
preempt disable loop in the first place, does not have this issue.

(Also added "attn: Steve" for the tracing question, to get his attention
since this thread is very long).
Steven, any thoughts on how rcu_ftrace_dump() can affect grace-period
durations or other RCU parts? Do you see how it could impact the RCU GP
thread if at all? I did setup RT priority 10 for the thread.

thanks,

- Joel