Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> Ingo Molnar <mingo@elte.hu> wrote:
> >
> > I have this fix queued up currently:
> >
> >  09223371deac: rcu: Use softirq to address performance regression
> 
> I really don't think that is even close to enough.

Yeah.

> It still does all the callbacks in the threads, and according to 
> Peter, about half the rcu time in the threads remained..

You are right - things that are a few percent on a 24 core machine 
will definitely go exponentially worse on larger boxen. We'll get rid 
of the kthreads entirely.

The funny thing about this workload is that context-switches are 
really a fastpath here and we are using anonymous IRQ-triggered 
softirqs embedded in random task contexts as a workaround for that.

[ I think we'll have to revisit this issue and do it properly:
  quiescent state is mostly defined by context-switches here, so we
  could do the RCU callbacks from the task that turns a CPU
  quiescent, right in the scheduler context-switch path - perhaps
  with an option for SCHED_FIFO tasks to *not* do GC.

  That could possibly be more cache-efficient than softirq execution,
  as we'll process a still-hot pool of callbacks instead of doing
  them only once per timer tick. It will also make the RCU GC
  behavior HZ independent. ]

In any case the proxy kthread model clearly sucked, no argument about 
that.

Thanks,

	Ingo