Re: [PATCH 01/10] irq_work: Introduce void irq work
On Sat, Jul 19, 2014 at 02:44:12AM +0200, Frederic Weisbecker wrote:
> Being able to trigger an empty IPI appears to be useless in the first
> place. Yet it is expected to be very useful for callers who just need
> to execute irq_enter() or irq_exit() to a remote target.
>
> More precisely this is going to be useful for the nohz subsystem which
> often needs a remote CPU to reschedule its tick when some state changed
> and require periodicity for any reason. Similar cases have been handled
> with random IPIs until now. But they surely bring unwanted overhead
> all along since they are all dedicated for specific tasks.
>
> Triggering an irq work/smp_call_function IPI should be enough to solve
> that. If competing and spurious IPIs become a problem, we can still
> optimize that later.
>
> Cc: Ingo Molnar
> Cc: Paul E. McKenney
> Cc: Peter Zijlstra
> Cc: Steven Rostedt
> Cc: Thomas Gleixner
> Cc: Viresh Kumar
> Signed-off-by: Frederic Weisbecker
Reviewed-by: Paul E. McKenney
> ---
> include/linux/irq_work.h | 1 +
> kernel/irq_work.c| 21 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
> index bf9422c..b2ad065 100644
> --- a/include/linux/irq_work.h
> +++ b/include/linux/irq_work.h
> @@ -36,6 +36,7 @@ bool irq_work_queue(struct irq_work *work);
>
> #ifdef CONFIG_SMP
> bool irq_work_queue_on(struct irq_work *work, int cpu);
> +void irq_work_void_on(int cpu);
> #endif
>
> void irq_work_run(void);
> diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> index 4b0a890..36b7fb2 100644
> --- a/kernel/irq_work.c
> +++ b/kernel/irq_work.c
> @@ -81,6 +81,27 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
> return true;
> }
> EXPORT_SYMBOL_GPL(irq_work_queue_on);
> +
> +/**
> + * irq_work_void_on(): Run a void IRQ on the target
> + * @cpu: The cpu to run the IRQ on
> + *
> + * Run a void IRQ for its own sake on the target. It's generally
> + * useful for callers which want to run irq_enter() or irq_exit()
> + * on a remote CPU.
> + */
> +void irq_work_void_on(int cpu)
> +{
> + /*
> + * NOTE: we could optimize that and spare some IPIs
> + * after checking that raised_list isn't empty before raising.
> + * This can't be done properly without cmpxchg() though so
> + * it may make things worse after all. But lets leave that
> + * possibility open in case people report such issue in the
> + * future.
> + */
> + arch_send_call_function_single_ipi(cpu);
> +}
> #endif
>
> /* Enqueue the irq work @work on the current CPU */
> --
> 1.8.3.1
>
--
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/
Re: [PATCH 01/10] irq_work: Introduce void irq work
On Sat, Jul 19, 2014 at 02:44:12AM +0200, Frederic Weisbecker wrote:
Being able to trigger an empty IPI appears to be useless in the first
place. Yet it is expected to be very useful for callers who just need
to execute irq_enter() or irq_exit() to a remote target.
More precisely this is going to be useful for the nohz subsystem which
often needs a remote CPU to reschedule its tick when some state changed
and require periodicity for any reason. Similar cases have been handled
with random IPIs until now. But they surely bring unwanted overhead
all along since they are all dedicated for specific tasks.
Triggering an irq work/smp_call_function IPI should be enough to solve
that. If competing and spurious IPIs become a problem, we can still
optimize that later.
Cc: Ingo Molnar mi...@kernel.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
include/linux/irq_work.h | 1 +
kernel/irq_work.c| 21 +
2 files changed, 22 insertions(+)
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index bf9422c..b2ad065 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -36,6 +36,7 @@ bool irq_work_queue(struct irq_work *work);
#ifdef CONFIG_SMP
bool irq_work_queue_on(struct irq_work *work, int cpu);
+void irq_work_void_on(int cpu);
#endif
void irq_work_run(void);
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 4b0a890..36b7fb2 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -81,6 +81,27 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
return true;
}
EXPORT_SYMBOL_GPL(irq_work_queue_on);
+
+/**
+ * irq_work_void_on(): Run a void IRQ on the target
+ * @cpu: The cpu to run the IRQ on
+ *
+ * Run a void IRQ for its own sake on the target. It's generally
+ * useful for callers which want to run irq_enter() or irq_exit()
+ * on a remote CPU.
+ */
+void irq_work_void_on(int cpu)
+{
+ /*
+ * NOTE: we could optimize that and spare some IPIs
+ * after checking that raised_list isn't empty before raising.
+ * This can't be done properly without cmpxchg() though so
+ * it may make things worse after all. But lets leave that
+ * possibility open in case people report such issue in the
+ * future.
+ */
+ arch_send_call_function_single_ipi(cpu);
+}
#endif
/* Enqueue the irq work @work on the current CPU */
--
1.8.3.1
--
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/
[PATCH 01/10] irq_work: Introduce void irq work
Being able to trigger an empty IPI appears to be useless in the first
place. Yet it is expected to be very useful for callers who just need
to execute irq_enter() or irq_exit() to a remote target.
More precisely this is going to be useful for the nohz subsystem which
often needs a remote CPU to reschedule its tick when some state changed
and require periodicity for any reason. Similar cases have been handled
with random IPIs until now. But they surely bring unwanted overhead
all along since they are all dedicated for specific tasks.
Triggering an irq work/smp_call_function IPI should be enough to solve
that. If competing and spurious IPIs become a problem, we can still
optimize that later.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/irq_work.h | 1 +
kernel/irq_work.c| 21 +
2 files changed, 22 insertions(+)
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index bf9422c..b2ad065 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -36,6 +36,7 @@ bool irq_work_queue(struct irq_work *work);
#ifdef CONFIG_SMP
bool irq_work_queue_on(struct irq_work *work, int cpu);
+void irq_work_void_on(int cpu);
#endif
void irq_work_run(void);
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 4b0a890..36b7fb2 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -81,6 +81,27 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
return true;
}
EXPORT_SYMBOL_GPL(irq_work_queue_on);
+
+/**
+ * irq_work_void_on(): Run a void IRQ on the target
+ * @cpu: The cpu to run the IRQ on
+ *
+ * Run a void IRQ for its own sake on the target. It's generally
+ * useful for callers which want to run irq_enter() or irq_exit()
+ * on a remote CPU.
+ */
+void irq_work_void_on(int cpu)
+{
+ /*
+* NOTE: we could optimize that and spare some IPIs
+* after checking that raised_list isn't empty before raising.
+* This can't be done properly without cmpxchg() though so
+* it may make things worse after all. But lets leave that
+* possibility open in case people report such issue in the
+* future.
+*/
+ arch_send_call_function_single_ipi(cpu);
+}
#endif
/* Enqueue the irq work @work on the current CPU */
--
1.8.3.1
--
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/
[PATCH 01/10] irq_work: Introduce void irq work
Being able to trigger an empty IPI appears to be useless in the first
place. Yet it is expected to be very useful for callers who just need
to execute irq_enter() or irq_exit() to a remote target.
More precisely this is going to be useful for the nohz subsystem which
often needs a remote CPU to reschedule its tick when some state changed
and require periodicity for any reason. Similar cases have been handled
with random IPIs until now. But they surely bring unwanted overhead
all along since they are all dedicated for specific tasks.
Triggering an irq work/smp_call_function IPI should be enough to solve
that. If competing and spurious IPIs become a problem, we can still
optimize that later.
Cc: Ingo Molnar mi...@kernel.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Steven Rostedt rost...@goodmis.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 | 1 +
kernel/irq_work.c| 21 +
2 files changed, 22 insertions(+)
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index bf9422c..b2ad065 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -36,6 +36,7 @@ bool irq_work_queue(struct irq_work *work);
#ifdef CONFIG_SMP
bool irq_work_queue_on(struct irq_work *work, int cpu);
+void irq_work_void_on(int cpu);
#endif
void irq_work_run(void);
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 4b0a890..36b7fb2 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -81,6 +81,27 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
return true;
}
EXPORT_SYMBOL_GPL(irq_work_queue_on);
+
+/**
+ * irq_work_void_on(): Run a void IRQ on the target
+ * @cpu: The cpu to run the IRQ on
+ *
+ * Run a void IRQ for its own sake on the target. It's generally
+ * useful for callers which want to run irq_enter() or irq_exit()
+ * on a remote CPU.
+ */
+void irq_work_void_on(int cpu)
+{
+ /*
+* NOTE: we could optimize that and spare some IPIs
+* after checking that raised_list isn't empty before raising.
+* This can't be done properly without cmpxchg() though so
+* it may make things worse after all. But lets leave that
+* possibility open in case people report such issue in the
+* future.
+*/
+ arch_send_call_function_single_ipi(cpu);
+}
#endif
/* Enqueue the irq work @work on the current CPU */
--
1.8.3.1
--
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/
