lkml.org 
[lkml]   [2011]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex

* 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


\
 
 \ /
  Last update: 2011-06-16 09:09    [W:0.162 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site