From: Tejun Heo <tj@kernel.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Kevin Hilman <khilman@linaro.org>,
Mike Galbraith <bitbucket@online.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 3/4] workqueue: Add anon workqueue sysfs hierarchy
Date: Sun, 30 Mar 2014 09:01:39 -0400 [thread overview]
Message-ID: <20140330130139.GD8942@htj.dyndns.org> (raw)
In-Reply-To: <1395940862-31428-4-git-send-email-fweisbec@gmail.com>
On Thu, Mar 27, 2014 at 06:21:01PM +0100, Frederic Weisbecker wrote:
> We call "anon workqueues" the set of unbound workqueues that don't
> carry the WQ_SYSFS flag.
>
> They are a problem nowadays because people who work on CPU isolation
> (HPC, Real time, etc...) want to be able to migrate all the unbound
> workqueues away to a single housekeeping CPU. This control is possible
> through sysfs but only with WQ_SYSFS workqueues.
>
> Now we need to deal with the other unbound workqueues. There is two
> possible solutions:
>
> 1) Implement a sysfs directory for each unbound !WQ_SYSFS. This could
> be done with a specific Kconfig to make sure that these workqueue
> won't be considered as a stable ABI. But we all know that all distros
> will enable this Kconfig symbol and that a warning in the Kconfig help
> text won't protect against anything.
>
> 2) Implement a single sysfs directory containing only the cpumask file
> to the control the affinity of all the !WQ_SYSFS workqueues.
>
> This patch implements the second solution but only for non-ordered
> unbound workqueues. Ordered workqueues need a special treatment and
> will be handled in a subsequent patch.
I'm not really sure this is the good approach. I think I wrote this
way back but wouldn't it make more sense to allow userland to restrict
the cpus which are allowed to all unbound cpus. As currently
implemented, setting WQ_SYSFS to give userland more control would
escape that workqueue from this global mask as a side effect, which is
a surprising behavior and doesn't make much sense to me. I think it
would make far more sense to implement a knob which controls which
cpus are available to *all* unbound workqueue including the default
fallback one. That way it's way more consistent and I'm pretty sure
the code would be fairly simple too. All it needs to do is
restricting the online cpus that unbound workqueues see.
Thanks.
--
tejun
next prev parent reply other threads:[~2014-03-30 13:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 17:20 [PATCH 0/4] workqueue: Control cpu affinity of all unbound workqueues v2 Frederic Weisbecker
2014-03-27 17:20 ` [PATCH 1/4] workqueue: Move workqueue bus attr to device attribute Frederic Weisbecker
2014-04-03 7:09 ` Viresh Kumar
2014-04-24 13:48 ` Frederic Weisbecker
2014-03-27 17:21 ` [PATCH 2/4] workqueues: Account unbound workqueue in a seperate list Frederic Weisbecker
2014-03-30 12:57 ` Tejun Heo
2014-04-03 14:48 ` Frederic Weisbecker
2014-04-03 15:01 ` Tejun Heo
2014-04-03 15:43 ` Frederic Weisbecker
2014-03-27 17:21 ` [PATCH 3/4] workqueue: Add anon workqueue sysfs hierarchy Frederic Weisbecker
2014-03-30 13:01 ` Tejun Heo [this message]
2014-04-03 14:42 ` Frederic Weisbecker
2014-04-03 14:58 ` Tejun Heo
2014-04-03 15:05 ` Frederic Weisbecker
2014-04-03 7:07 ` Viresh Kumar
2014-03-27 17:21 ` [PATCH 4/4] workqueue: Include ordered workqueues in anon workqueue sysfs interface Frederic Weisbecker
2014-03-31 12:50 ` Lai Jiangshan
2014-03-31 13:15 ` Lai Jiangshan
2014-04-03 15:59 ` Frederic Weisbecker
2014-04-15 9:58 ` [PATCH] workqueue: allow changing attributions of ordered workqueue Lai Jiangshan
2014-04-15 12:25 ` Frederic Weisbecker
2014-04-15 15:19 ` Lai Jiangshan
2014-04-23 0:04 ` Frederic Weisbecker
2014-04-23 2:16 ` Lai Jiangshan
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=20140330130139.GD8942@htj.dyndns.org \
--to=tj@kernel.org \
--cc=bitbucket@online.de \
--cc=cl@linux.com \
--cc=fweisbec@gmail.com \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--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
all inboxes | Powered by JetHome®