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

[Ingo Molnar <mingo@elte.hu>]

* 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>