From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Rik van Riel <riel@redhat.com>,
"Luis Claudio R. Goncalves" <lclaudio@uudg.org>
Subject: Re: [RFC] workqueue: avoiding unbounded wq on isolated CPUs by default
Date: Tue, 21 Jul 2015 10:55:25 +0200 [thread overview]
Message-ID: <1437468925.12755.57.camel@gmail.com> (raw)
In-Reply-To: <1437292973.3505.83.camel@gmail.com>
On Sun, 2015-07-19 at 10:02 +0200, Mike Galbraith wrote:
> Why do we do nothing about these allegedly unbound work items?
My box seems to think the answer is: no reason other than nobody having
asked the source to please not do that. Guess I'll go ask a NUMA box.
workqueue: RR schedule unbound work to CPUs in wq_unbound_cpumask
WORK_CPU_UNBOUND work items queued to a bound workqueue always run
locally. This is a good thing normally, as it keeps us from bouncing
work all over the place like ping-pong balls in a nuclear fission demo.
When the user has asked us to keep unbound work away from certain CPUs
however, honor that request, select a CPU from wq_unbound_cpumask.
Not-signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
---
kernel/workqueue.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -301,6 +301,9 @@ static bool workqueue_freezing; /* PL:
static cpumask_var_t wq_unbound_cpumask; /* PL: low level cpumask for all unbound wqs */
+/* CPU where WORK_CPU_UNBOUND work was last round robin scheduled from this CPU */
+static DEFINE_PER_CPU(unsigned int, wq_unbound_rr_cpu_last);
+
/* the per-cpu worker pools */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
cpu_worker_pools);
@@ -1294,6 +1297,24 @@ static bool is_chained_work(struct workq
return worker && worker->current_pwq->wq == wq;
}
+/*
+ * When queueing WORK_CPU_UNBOUND work to a !WQ_UNBOUND queue, round
+ * robin among wq_unbound_cpumask to avoid perturbing sensitive tasks.
+ */
+static unsigned int select_round_robin_cpu(unsigned int cpu)
+{
+ if (cpumask_test_cpu(cpu, wq_unbound_cpumask))
+ return cpu;
+ if (cpumask_empty(wq_unbound_cpumask))
+ return cpu;
+ cpu = __this_cpu_read(wq_unbound_rr_cpu_last);
+ cpu = cpumask_next_and(cpu, wq_unbound_cpumask, cpu_online_mask);
+ if (cpu >= nr_cpu_ids)
+ cpu = 0;
+ __this_cpu_write(wq_unbound_rr_cpu_last, cpu);
+ return cpu;
+}
+
static void __queue_work(int cpu, struct workqueue_struct *wq,
struct work_struct *work)
{
@@ -1322,9 +1343,11 @@ static void __queue_work(int cpu, struct
cpu = raw_smp_processor_id();
/* pwq which will be used unless @work is executing elsewhere */
- if (!(wq->flags & WQ_UNBOUND))
+ if (!(wq->flags & WQ_UNBOUND)) {
+ if (req_cpu == WORK_CPU_UNBOUND)
+ cpu = select_round_robin_cpu(cpu);
pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
- else
+ } else
pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
/*
next prev parent reply other threads:[~2015-07-21 8:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 19:16 [RFC] workqueue: avoiding unbounded wq on isolated CPUs by default Daniel Bristot de Oliveira
2015-07-16 19:24 ` Tejun Heo
2015-07-17 4:26 ` Mike Galbraith
2015-07-17 15:27 ` Tejun Heo
2015-07-17 15:35 ` Frederic Weisbecker
2015-07-17 15:43 ` Tejun Heo
2015-07-17 17:15 ` Mike Galbraith
2015-07-18 13:36 ` Frederic Weisbecker
2015-07-18 15:48 ` Mike Galbraith
2015-07-19 8:02 ` Mike Galbraith
2015-07-19 12:19 ` Mike Galbraith
2015-07-21 8:55 ` Mike Galbraith [this message]
2015-07-22 5:24 ` [patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs Mike Galbraith
2015-07-22 12:43 ` [PATCH] workqueue: avoiding unbounded wq on isolated CPUs by default Daniel Bristot de Oliveira
2015-07-22 14:11 ` [patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs Tejun Heo
2015-07-22 14:55 ` Mike Galbraith
2015-07-22 15:19 ` Mike Galbraith
2015-07-22 15:25 ` Tejun Heo
2015-07-24 3:38 ` Mike Galbraith
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=1437468925.12755.57.camel@gmail.com \
--to=umgwanakikbuti@gmail.com \
--cc=bristot@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=lclaudio@uudg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=tj@kernel.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.