From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
"Luis Claudio R. Goncalves" <lclaudio@uudg.org>
Subject: [patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs
Date: Wed, 22 Jul 2015 07:24:46 +0200 [thread overview]
Message-ID: <1437542686.3106.55.camel@gmail.com> (raw)
In-Reply-To: <1437468925.12755.57.camel@gmail.com>
On Tue, 2015-07-21 at 10:55 +0200, Mike Galbraith wrote:
> 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.
My [128] socket boxen show zero signs of caring, and it's dirt simple,
so it's no longer an experiment. Fly or die little patchlet...
WORK_CPU_UNBOUND work items queued to a bound workqueue always run
locally. This is a good thing normally, but not when the user has
asked us to keep unbound work away from certain CPUs. Round robin
these to wq_unbound_cpumask CPUs instead, as perturbation avoidance
trumps performance.
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-22 5:24 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
2015-07-22 5:24 ` Mike Galbraith [this message]
2015-07-22 12:43 ` [PATCH] " 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=1437542686.3106.55.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.