From: Frederic Weisbecker <fweisbec@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Christoph Lameter <cl@linux.com>,
Kevin Hilman <khilman@linaro.org>,
Mike Galbraith <bitbucket@online.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Tejun Heo <tj@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>
Subject: [RFC PATCH 0/3] workqueue: Control cpu affinity of !WQ_SYSFS unbound workqueues
Date: Fri, 14 Mar 2014 17:38:48 +0100 [thread overview]
Message-ID: <1394815131-17271-1-git-send-email-fweisbec@gmail.com> (raw)
There are several types of workqueues. Some of them are bound to specific
CPUs, some others are unbound and can be executed on any CPU.
A tiny subset of the unbound workqueues have a sysfs representation
in /sys/devices/virtual/workqueue/ and have a cpumask file than can
be used to tweak their CPU affinity.
But the vast majority of unbound workqueues aren't visible in sysfs.
They are a problem nowaday because people who work on CPU isolation
(HPC, Real time, etc...) want to be able to migrate all the unbound
workqueues away from specific CPUs.
There are several possible solutions to solve this:
1) Affine the !WQ_SYSFS unbound workqueues to the CPUs outside the
full dynticks mask. Full dynticks is expected to be a component in
many CPU isolation configurations and its CPU mapping can be a good
way to retrieve the desired set of isolated CPUs.
On the drawbacks though we can notice the lack of consistency with
WQ_SYSFS workqueue affinity interface, issues with ordering between
workqueue and dynticks subsystem initialization, intrusion from
the workqueue subsystem on dynticks internals.
2) Implement a sysfs directory for each unbound !WQ_SYSFS. That sounds
like a very nice solution as it uses existing and known interface.
But workqueues appearing in the sysfs hierarchy are subject to become
stable ABIs. And this is definetly not what we want.
This could be worked around with a specific Kconfig to make sure that
these workqueues won't be considered as a stable ABI. But we all know
that all distros will enable this Kconfig symbol and that nobody
reads, nor care about, warnings in Kconfig help text which thereby won't
protect us against anything.
3) Implement a single sysfs directory to map properties of all !WQ_SYSFS
unbound workqueues. It would contain only the cpumask file to control
the affinity of all these workqueues. But more can be added later.
This complexifies the code a bit although not that much compared to
solution 2 which requires some plumbling to cope with workqueues created
before sysfs, as reported by Mike (I played with that a bit as well, as I
took that direction initially). But it deals with all issues previously
described.
This patchset explores the third solution.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
core/workqueue-anon-sysfs
Thanks,
Frederic
---
Frederic Weisbecker (3):
workqueue: Move workqueue bus attr to device attribute
workqueues: Account unbound workqueue in a seperate list
workqueue: Add anon workqueue sysfs hierarchy
kernel/workqueue.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 140 insertions(+), 10 deletions(-)
next reply other threads:[~2014-03-14 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 16:38 Frederic Weisbecker [this message]
2014-03-14 16:38 ` [PATCH 1/3] workqueue: Move workqueue bus attr to device attribute Frederic Weisbecker
2014-03-14 16:38 ` [PATCH 2/3] workqueues: Account unbound workqueue in a seperate list Frederic Weisbecker
2014-03-14 18:17 ` Kevin Hilman
2014-03-15 12:40 ` Frederic Weisbecker
2014-03-14 16:38 ` [PATCH 3/3] workqueue: Add anon workqueue sysfs hierarchy Frederic Weisbecker
2014-03-14 19:08 ` Kevin Hilman
2014-03-17 14:02 ` Frederic Weisbecker
2014-03-22 17:01 ` Frederic Weisbecker
2014-03-22 18:55 ` Tejun Heo
2014-03-22 22:04 ` Frederic Weisbecker
2014-03-14 18:06 ` [RFC PATCH 0/3] workqueue: Control cpu affinity of !WQ_SYSFS unbound workqueues Kevin Hilman
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=1394815131-17271-1-git-send-email-fweisbec@gmail.com \
--to=fweisbec@gmail.com \
--cc=bitbucket@online.de \
--cc=cl@linux.com \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tj@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox