Re: [PATCH RFC tip/core/rcu 09/16] rcu-tasks: Add an RCU-tasks rude variant

[Paul E. McKenney]

On Mon, Mar 16, 2020 at 04:17:51PM -0400, Joel Fernandes wrote:
> On Mon, Mar 16, 2020 at 3:47 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Mar 12, 2020 at 11:16:55AM -0700, paulmck@xxxxxxxxxx wrote:
> > > From: "Paul E. McKenney" <paulmck@xxxxxxxxxx>
> > >
> > > This commit adds a "rude" variant of RCU-tasks that has as quiescent
> > > states schedule(), cond_resched_tasks_rcu_qs(), userspace execution,
> > > and (in theory, anyway) cond_resched().  Updates make use of IPIs and
> > > force an IPI and a context switch on each online CPU.  This variant
> > > is useful in some situations in tracing.
> >
> > Would it be possible to better clarify that the "rude version" works only
> > from preempt-disabled regions? Is that also true for the "non-rude" version?
> >
> > Also it would be good to clarify better in cover letter, how these new
> > flavors relate to the existing Tasks-RCU implementation.
> >
> > In the existing one, a quiescent state is a task updating its context switch
> > counters such that it went to sleep at least once, implying there is no
> > chance it is on an about to be destroyed trampoline.
> >
> > However, here we are trying to determine if a task state is no longer on an
> > RQ (which I gleaned from the first patch). Sounds very similar, would the
> > context switch counters not help in that determination as well? If it is Ok,
> > it would be good to describe in cover letter about what is exactly is a
> > quiescent state and what exactly is a reader section in the cover letter, for
> > both non-rude and rude version. Thanks!
> 
> Just curious, why is the "rude" version better than SRCU? Seems the
> schedule_on_each_cpu() would be much slower than SRCU especially if
> there are 1000s of CPUs involved. Is there any reason that is a better
> alternative?

The rude version has much faster readers, and the story I hear is that
there are not expected to be all that many concurrent updaters.

But to get more detail, why not ask Steven why he chose not to use SRCU?
(I know the story for the BPF guys, and it is because of SRCU's read-side
overhead.)

							Thanx, Paul