On Mon, 2012-10-29 at 16:27 -0400, Steven Rostedt wrote: > plain text document attachment > (0004-x86-New-cpuset-nohz-irq-vector.patch) > From: Frederic Weisbecker <fweis...@gmail.com> > > We need a way to send an IPI (remote or local) in order to > asynchronously restart the tick for CPUs in nohz adaptive mode. > > This must be asynchronous such that we can trigger it with irqs > disabled. This must be usable as a self-IPI as well for example > in cases where we want to avoid random dealock scenario while > restarting the tick inline otherwise. > > This only settles the x86 backend. The core tick restart function > will be defined in a later patch. > > [CHECKME: Perhaps we instead need to use irq work for self IPIs. > But we also need a way to send async remote IPIs.]
Probably just use irq_work for self ipis, and normal ipis for other CPUs. Also, what reason do we have to force a task out of nohz? IOW, do we really need this? Also, perhaps we could just tag onto the schedule_ipi() function instead of having to create a new IPI for all archs? -- Steve > > 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: Daniel Lezcano <daniel.lezc...@linaro.org> > Cc: Geoff Levand <ge...@infradead.org> > Cc: Gilad Ben Yossef <gi...@benyossef.com> > Cc: Hakan Akkan <hakanak...@gmail.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Kevin Hilman <khil...@ti.com> > Cc: Max Krasnyansky <m...@qualcomm.com> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.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> -- 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/
