From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, Kevin Hilman <khilman@linaro.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Zoran Markovic <zoran.markovic@linaro.org>,
linux-kernel@vger.kernel.org,
Shaibal Dutta <shaibal.dutta@broadcom.com>,
Dipankar Sarma <dipankar@in.ibm.com>
Subject: Re: [RFC PATCH] rcu: move SRCU grace period work to power efficient workqueue
Date: Wed, 12 Feb 2014 16:33:11 -0800 [thread overview]
Message-ID: <20140213003311.GJ4250@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140212230454.GA14383@localhost.localdomain>
On Thu, Feb 13, 2014 at 12:04:57AM +0100, Frederic Weisbecker wrote:
> On Wed, Feb 12, 2014 at 11:59:22AM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 12, 2014 at 02:23:54PM -0500, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Wed, Feb 12, 2014 at 11:02:41AM -0800, Paul E. McKenney wrote:
> > > > +2. Use the /sys/devices/virtual/workqueue/*/cpumask sysfs files
> > > > + to force the WQ_SYSFS workqueues to run on the specified set
> > > > + of CPUs. The set of WQ_SYSFS workqueues can be displayed using
> > > > + "ls sys/devices/virtual/workqueue".
> > >
> > > One thing to be careful about is that once published, it becomes part
> > > of userland visible interface. Maybe adding some words warning
> > > against sprinkling WQ_SYSFS willy-nilly is a good idea?
> >
> > Good point! How about the following?
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > Documentation/kernel-per-CPU-kthreads.txt: Workqueue affinity
> >
> > This commit documents the ability to apply CPU affinity to WQ_SYSFS
> > workqueues, thus offloading them from the desired worker CPUs.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Cc: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Tejun Heo <tj@kernel.org>
> >
> > diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
> > index 827104fb9364..214da3a47a68 100644
> > --- a/Documentation/kernel-per-CPU-kthreads.txt
> > +++ b/Documentation/kernel-per-CPU-kthreads.txt
> > @@ -162,7 +162,16 @@ Purpose: Execute workqueue requests
> > To reduce its OS jitter, do any of the following:
> > 1. Run your workload at a real-time priority, which will allow
> > preempting the kworker daemons.
> > -2. Do any of the following needed to avoid jitter that your
> > +2. Use the /sys/devices/virtual/workqueue/*/cpumask sysfs files
> > + to force the WQ_SYSFS workqueues to run on the specified set
> > + of CPUs. The set of WQ_SYSFS workqueues can be displayed using
> > + "ls sys/devices/virtual/workqueue". That said, the workqueues
> > + maintainer would like to caution people against indiscriminately
> > + sprinkling WQ_SYSFS across all the workqueues. The reason for
> > + caution is that it is easy to add WQ_SYSFS, but because sysfs
> > + is part of the formal user/kernel API, it can be nearly impossible
> > + to remove it, even if its addition was a mistake.
> > +3. Do any of the following needed to avoid jitter that your
>
> Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
>
> I just suggest we append a small explanation about what WQ_SYSFS is about.
> Like:
Fair point! I wordsmithed it into the following. Seem reasonable?
Thanx, Paul
------------------------------------------------------------------------
Documentation/kernel-per-CPU-kthreads.txt: Workqueue affinity
This commit documents the ability to apply CPU affinity to WQ_SYSFS
workqueues, thus offloading them from the desired worker CPUs.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
index 827104fb9364..f3cd299fcc41 100644
--- a/Documentation/kernel-per-CPU-kthreads.txt
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -162,7 +162,18 @@ Purpose: Execute workqueue requests
To reduce its OS jitter, do any of the following:
1. Run your workload at a real-time priority, which will allow
preempting the kworker daemons.
-2. Do any of the following needed to avoid jitter that your
+2. A given workqueue can be made visible in the sysfs filesystem
+ by passing the WQ_SYSFS to that workqueue's alloc_workqueue().
+ Such a workqueue can be confined to a given subset of the
+ CPUs using the /sys/devices/virtual/workqueue/*/cpumask sysfs
+ files. The set of WQ_SYSFS workqueues can be displayed using
+ "ls sys/devices/virtual/workqueue". That said, the workqueues
+ maintainer would like to caution people against indiscriminately
+ sprinkling WQ_SYSFS across all the workqueues. The reason for
+ caution is that it is easy to add WQ_SYSFS, but because sysfs is
+ part of the formal user/kernel API, it can be nearly impossible
+ to remove it, even if its addition was a mistake.
+3. Do any of the following needed to avoid jitter that your
application cannot tolerate:
a. Build your kernel with CONFIG_SLUB=y rather than
CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
next prev parent reply other threads:[~2014-02-13 0:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 19:53 [RFC PATCH] rcu: move SRCU grace period work to power efficient workqueue Zoran Markovic
2014-01-31 20:10 ` Zoran Markovic
2014-02-10 10:08 ` Lai Jiangshan
2014-02-10 18:47 ` Paul E. McKenney
2014-02-12 18:23 ` Frederic Weisbecker
2014-02-12 19:02 ` Paul E. McKenney
2014-02-12 19:23 ` Tejun Heo
2014-02-12 19:59 ` Paul E. McKenney
2014-02-12 20:13 ` Tejun Heo
2014-02-12 23:04 ` Frederic Weisbecker
2014-02-13 0:33 ` Paul E. McKenney [this message]
2014-02-13 1:30 ` Lai Jiangshan
2014-02-13 14:05 ` Frederic Weisbecker
2014-02-14 23:24 ` Kevin Hilman
2014-02-15 7:36 ` Mike Galbraith
2014-02-16 16:41 ` Paul E. McKenney
2014-02-17 4:50 ` Mike Galbraith
2014-02-19 7:00 ` Mike Galbraith
2014-02-24 17:55 ` Kevin Hilman
2014-02-24 18:25 ` Mike Galbraith
2014-02-27 15:08 ` Frederic Weisbecker
2014-03-10 9:52 ` Viresh Kumar
2014-02-17 5:26 ` Mike Galbraith
2014-02-27 14:43 ` Frederic Weisbecker
2014-02-27 15:22 ` 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=20140213003311.GJ4250@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=fweisbec@gmail.com \
--cc=khilman@linaro.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shaibal.dutta@broadcom.com \
--cc=tj@kernel.org \
--cc=zoran.markovic@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.