From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, Kevin Hilman <khilman@linaro.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 1/3] irq_work: Implement remote queueing
Date: Wed, 14 May 2014 11:06:29 +0200 [thread overview]
Message-ID: <20140514090629.GC30445@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1400019956-25511-2-git-send-email-fweisbec@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]
On Wed, May 14, 2014 at 12:25:54AM +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 <peterz@infradead.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
> include/linux/irq_work.h | 2 ++
> kernel/irq_work.c | 19 ++++++++++++++++++-
> kernel/smp.c | 4 ++++
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
> index 19ae05d..ae44aa2 100644
> --- a/include/linux/irq_work.h
> +++ b/include/linux/irq_work.h
> @@ -33,6 +33,8 @@ void init_irq_work(struct irq_work *work, void (*func)(struct irq_work *))
> #define DEFINE_IRQ_WORK(name, _f) struct irq_work name = { .func = (_f), }
>
> bool irq_work_queue(struct irq_work *work);
> +bool irq_work_queue_on(struct irq_work *work, int cpu);
> +
> void irq_work_run(void);
> void irq_work_sync(struct irq_work *work);
>
> diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> index a82170e..9f9be55 100644
> --- a/kernel/irq_work.c
> +++ b/kernel/irq_work.c
> @@ -56,11 +56,28 @@ void __weak arch_irq_work_raise(void)
> }
>
> /*
> - * Enqueue the irq_work @entry unless it's already pending
> + * Enqueue the irq_work @work on @cpu unless it's already pending
> * somewhere.
> *
> * Can be re-enqueued while the callback is still in progress.
> */
> +bool irq_work_queue_on(struct irq_work *work, int cpu)
> +{
> + /* Only queue if not already pending */
> + if (!irq_work_claim(work))
> + return false;
> +
> + /* All work should have been flushed before going offline */
> + WARN_ON_ONCE(cpu_is_offline(cpu));
WARN_ON_ONCE(in_nmi());
> +
> + llist_add(&work->llnode, &per_cpu(irq_work_list, cpu));
> + native_send_call_func_single_ipi(cpu);
At the very leastestest make that:
if (llist_add(&work->llnode, &per_cpu(irq_work_list, cpu)))
native_send_call_func_single_ipi(cpu);
But ideally, also test the IRQ_WORK_LAZY support, its weird to have that
only be supported for the other queue.
Hmm, why do we need that LAZY crap, that completely wrecks a perfectly
simple thing.
The changelog (bc6679aef673f), not the printk() usage make much sense,
printk() can't cause an IPI storm... printk() isn't fast enough to storm
anything.
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(irq_work_queue_on);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-05-14 9:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 22:25 [PATCH 0/3] nohz: Move nohz kick out of scheduler IPI, v5 Frederic Weisbecker
2014-05-13 22:25 ` [PATCH 1/3] irq_work: Implement remote queueing Frederic Weisbecker
2014-05-14 9:06 ` Peter Zijlstra [this message]
2014-05-14 9:10 ` Peter Zijlstra
2014-05-14 11:38 ` Frederic Weisbecker
2014-05-14 11:54 ` Peter Zijlstra
2014-05-14 12:11 ` Frederic Weisbecker
2014-05-14 12:41 ` Peter Zijlstra
2014-05-14 13:51 ` Frederic Weisbecker
2014-05-14 13:55 ` Peter Zijlstra
2014-05-14 14:28 ` Thomas Gleixner
2014-05-13 22:25 ` [PATCH 2/3] nohz: Move full nohz kick to its own IPI Frederic Weisbecker
2014-05-13 22:25 ` [PATCH 3/3] nohz: Use IPI implicit full barrier against rq->nr_running r/w Frederic Weisbecker
2014-05-14 9:09 ` Peter Zijlstra
2014-05-14 11:38 ` Frederic Weisbecker
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=20140514090629.GC30445@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--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.