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

["Paul E. McKenney" <paulmck@linux.ibm.com>]

On Sat, Jul 06, 2019 at 08:18:07AM -0400, Joel Fernandes wrote:
> 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.

I see a local_irq_save() a few lines into ftrace_dump() itself.  Am I
missing where interrupts are being re-enabled prior to the trace-dump
loop?

							Thanx, Paul