All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 01/10] irq_work: Introduce void irq work
Date: Mon, 21 Jul 2014 11:16:37 -0700	[thread overview]
Message-ID: <20140721181637.GK8690@linux.vnet.ibm.com> (raw)
In-Reply-To: <1405730661-9355-2-git-send-email-fweisbec@gmail.com>

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 <mingo@kernel.org>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>

Reviewed-by: Paul E. McKenney <paulmck@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
> 


  reply	other threads:[~2014-07-21 18:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-19  0:44 [RFC PATCH 00/10] nohz: Support sysidle (and some more cleanups) Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 01/10] irq_work: Introduce void irq work Frederic Weisbecker
2014-07-21 18:16   ` Paul E. McKenney [this message]
2014-07-19  0:44 ` [PATCH 02/10] nohz: Kick full dynticks timer targets with an empty IPI Frederic Weisbecker
2014-07-19  7:19   ` Peter Zijlstra
2014-07-19 13:18     ` Frederic Weisbecker
2014-07-19 13:47       ` Peter Zijlstra
2014-07-19 13:54         ` Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 03/10] rcu: Kick full dynticks CPU on extended grace period with a void IRQ Frederic Weisbecker
2014-07-21 18:16   ` Paul E. McKenney
2014-07-19  0:44 ` [PATCH 04/10] nohz: Appropriate timekeeper kick on sysidle break Frederic Weisbecker
2014-07-21 18:15   ` Paul E. McKenney
2014-07-19  0:44 ` [PATCH 05/10] smp: Fast path check on IPI list Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 06/10] nohz: Define meaningful symbol for nohz full timekeeper Frederic Weisbecker
2014-07-21 18:11   ` Paul E. McKenney
2014-07-21 18:12   ` Paul E. McKenney
2014-07-25 21:27     ` Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 07/10] nohz: Enforce timekeeping on CPU 0 Frederic Weisbecker
2014-07-19 17:31   ` Nicolas Pitre
2014-07-19 18:31     ` Peter Zijlstra
2014-07-19 18:46       ` Nicolas Pitre
2014-07-19 19:45         ` Peter Zijlstra
2014-07-20  1:07     ` Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 08/10] nohz: Fetch timekeeping max deferment only for timekeeper Frederic Weisbecker
2014-07-19  0:44 ` [PATCH 09/10] nohz: Switch nohz full timekeeper to dynticks idle on top of sysidle detection Frederic Weisbecker
2014-07-21 17:50   ` Paul E. McKenney
2014-07-19  0:44 ` [PATCH 10/10] nohz: Warn on illegal timekeeper switch in nohz full Frederic Weisbecker
2014-07-21 17:51   ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140721181637.GK8690@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.