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

Ingo Molnar
2011-06-16T22:39:53Z

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Thu, 2011-06-16 at 22:25 +0200, Ingo Molnar wrote:
>
> > > Whatever does the boosting will need to have process context
> > > and can be subject to delays, so that pretty much needs to be a
> > > kthread. But it will context-switch quite rarely, so should not
> > > be a problem.
> >
> > So user-return notifiers ought to be the ideal platform for that,
> > right? We don't even have to touch the scheduler: anything that
> > schedules will eventually return to user-space, at which point
> > the RCU GC magic can run.
> >
> > And user-return-notifiers can be triggered from IRQs as well.
> >
> > That allows us to get rid of softirqs altogether and maybe even
> > speed the whole thing up and allow it to be isolated better.
>
> I'm a little worried of relying on things returning to userspace.
>
> One could imagine something like a router appliance where userspace
> is essentially asleep forever and everything happens in the kernel
> (networking via softirq, maybe NFS kernel server, ...)

There's a crazy solution for that: the idle thread could process RCU
callbacks carefully, as if it was running user-space code.

/me runs

Ok, joke aside: this is simply a special case where the idle thread
generates RCU work via hardirqs. The idle thread is arguably special
and could be handled in a special way: a helper thread that executes
only in this case?

Thanks,

Ingo