lkml.org 
[lkml]   [2013]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tty^Wrcu/perf lockdep trace.
On Fri, Oct 04, 2013 at 09:03:52AM -0700, Paul E. McKenney wrote:
> The problem exists, but NOCB made it much more probable. With non-NOCB
> kernels, an irq-disabled call_rcu() invocation does a wake_up() only if
> there are more than 10,000 callbacks stacked up on the CPU. With a NOCB
> kernel, the wake_up() happens on the first callback.

Oh I see.. so I was hoping this was some NOCB crackbrained damage we
could still 'fix'.

And that wakeup is because we moved grace-period advancing into
kthreads, right?

> I am not too happy about the complexity of deferring, but maybe it is
> the right approach, at least assuming perf isn't going to whack me
> with a timer lock. ;-)

I'm not too thrilled about trying to move the call_rcu() usage either.

> Any other approaches that I am missing?

Probably; so the regular no-NOCB would be easy to work around by
providing me a call_rcu variant that never does the wakeup.

NOCB might be a little more difficult; depending on the reason why it
needs to do this wakeup on every single invocation; that seems
particularly expensive.

Man, RCU was so much easier when all it was was a strict per-cpu state
with timer-interrupt driven state machine; non of all this nonsense.


\
 
 \ /
  Last update: 2013-10-04 19:21    [W:1.172 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site