On Tue, Jun 03, 2014 at 04:40:18PM +0200, Frederic Weisbecker wrote: > irq work currently only supports local callbacks. However its code > is mostly ready to run remote callbacks and we have some potential user. > > The full nohz subsystem currently open codes its own remote irq work > on top of the scheduler ipi when it wants a CPU to reevaluate its next > tick. However this ad hoc solution bloats the scheduler IPI. > > Lets just extend the irq work subsystem to support remote queuing on top > of the generic SMP IPI to handle this kind of user. This shouldn't add > noticeable overhead. > > Suggested-by: Peter Zijlstra <pet...@infradead.org> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Kevin Hilman <khil...@linaro.org> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com>
Acked-by: Peter Zijlstra <pet...@infradead.org> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Viresh Kumar <viresh.ku...@linaro.org> > Signed-off-by: Frederic Weisbecker <fweis...@gmail.com> > --- > include/linux/irq_work.h | 2 ++ > kernel/irq_work.c | 22 +++++++++++++++++++++- > kernel/smp.c | 4 ++++ > 3 files changed, 27 insertions(+), 1 deletion(-) > @@ -198,6 +199,9 @@ void generic_smp_call_function_single_interrupt(void) > csd->func(csd->info); > csd_unlock(csd); > } > + > + /* Handle irq works queued remotely by irq_work_queue_on() */ > + irq_work_run(); > } One could possibly extend that comment by stating that we explicitly run the irq_work bits after the function bits, because the function bits are typically synchronous and have people waiting on them, while not so for the irq_works.
pgpVnGPG3C6g7.pgp
Description: PGP signature
