On Fri, Jul 06, 2012 at 02:00:13PM +0200, Frederic Weisbecker wrote: > Create a new config option under the RCU menu that put > CPUs under RCU extended quiescent state (as in dynticks > idle mode) when they run in userspace. This require > some contribution from architectures to hook into kernel > and userspace boundaries. > > Signed-off-by: Frederic Weisbecker <fweis...@gmail.com> > Cc: Alessio Igor Bogani <abog...@kernel.org> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Avi Kivity <a...@redhat.com> > Cc: Chris Metcalf <cmetc...@tilera.com> > Cc: Christoph Lameter <c...@linux.com> > Cc: Geoff Levand <ge...@infradead.org> > Cc: Gilad Ben Yossef <gi...@benyossef.com> > Cc: Hakan Akkan <hakanak...@gmail.com> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Josh Triplett <j...@joshtriplett.org> > Cc: Kevin Hilman <khil...@ti.com> > Cc: Max Krasnyansky <m...@qualcomm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Stephen Hemminger <shemmin...@vyatta.com> > Cc: Steven Rostedt <rost...@goodmis.org> > Cc: Sven-Thorsten Dietrich <thebigcorporat...@gmail.com> > Cc: Thomas Gleixner <t...@linutronix.de> > --- > arch/Kconfig | 13 +++++++++++++ > init/Kconfig | 10 ++++++++++ > kernel/rcutree.c | 4 ++++ > 3 files changed, 27 insertions(+), 0 deletions(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 8c3d957..c2e0ce4 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -274,4 +274,17 @@ config SECCOMP_FILTER > > See Documentation/prctl/seccomp_filter.txt for details. > > +config HAVE_RCU_USER_QS > + bool > + help > + Provide kernel entry/exit hooks necessary for userspace > + RCU extended quiescent state. Syscalls and exceptions > + low level handlers must be wrapped with a call to rcu_user_exit() > + on entry and rcu_user_enter() before resuming userspace. Irqs > + entry don't need to call rcu_user_exit() because their high level > + handlers are protected inside rcu_irq_enter/rcu_irq_exit() but > + preemption or signal handling on irq exit still need to be protected > + with a call to rcu_user_exit(). rcu_user_enter() must then be > + called back on irq exit when the preempted task is back on the CPU. > + > source "kernel/gcov/Kconfig" > diff --git a/init/Kconfig b/init/Kconfig > index d07dcf9..3a4af8f 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -441,6 +441,16 @@ config PREEMPT_RCU > This option enables preemptible-RCU code that is common between > the TREE_PREEMPT_RCU and TINY_PREEMPT_RCU implementations. > > +config RCU_USER_QS > + bool "Consider userspace as in RCU extended quiescent state" > + depends on HAVE_RCU_USER_QS && SMP
OK, I'll bite... Why the "SMP"? RCU could make good use of knowing about user-mode executing even in UP kernels. > + help > + This option sets hooks on kernel / userspace boundaries and > + puts RCU in extended quiescent state when the CPU runs in > + userspace. It means that when a CPU runs in userspace, it is > + excluded from the global RCU state machine and thus doesn't > + need to keep the timer tick on for RCU. > + > config RCU_FANOUT > int "Tree-based hierarchical RCU fanout value" > range 2 64 if 64BIT > diff --git a/kernel/rcutree.c b/kernel/rcutree.c > index 5541a07..64fc2cd 100644 > --- a/kernel/rcutree.c > +++ b/kernel/rcutree.c > @@ -423,6 +423,7 @@ void rcu_idle_enter(void) > } > EXPORT_SYMBOL_GPL(rcu_idle_enter); > > +#ifdef CONFIG_RCU_USER_QS > /** > * rcu_user_enter - inform RCU that we are resuming userspace. > * > @@ -436,6 +437,7 @@ void rcu_user_enter(void) > rcu_eqs_enter(1); > } > EXPORT_SYMBOL_GPL(rcu_user_enter); > +#endif > > > /** > @@ -561,6 +563,7 @@ void rcu_idle_exit(void) > } > EXPORT_SYMBOL_GPL(rcu_idle_exit); > > +#ifdef CONFIG_RCU_USER_QS > /** > * rcu_user_exit - inform RCU that we are exiting userspace. > * > @@ -572,6 +575,7 @@ void rcu_user_exit(void) > rcu_eqs_exit(1); > } > EXPORT_SYMBOL_GPL(rcu_user_exit); > +#endif > > /** > * rcu_user_exit_irq - inform RCU that we won't resume to userspace > -- > 1.7.5.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
