From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
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: Re: [patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs
Date: Wed, 22 Jul 2015 16:55:12 +0200 [thread overview]
Message-ID: <1437576912.3484.8.camel@gmail.com> (raw)
In-Reply-To: <20150722141148.GL15934@mtj.duckdns.org>
On Wed, 2015-07-22 at 10:11 -0400, Tejun Heo wrote:
> On Wed, Jul 22, 2015 at 07:24:46AM +0200, Mike Galbraith wrote:
> > 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
>
> The constant name used there is a bit misleading but you can't put
> work items which are queued w/ queue_work() on foreign cpus by
> default. queue_work() has always guaranteed local execution. The
> problem is that workqueue can't currently tell whether a queue_work()
> user expects cpu locality for correctness or optimization. It'd be
> great if we introduce queue_work_on_local() or sth and replace
> correctness ones with it but that involves auditing each and every
> queue_work() usage. If anybody is up for the task, I'd be happy to
> help.
Oh well. That puts a big dent in the utility of wq_unbound_cpumask, but
too bad. If someone has a big enough HPC itch, they'll scratch it.
-Mike
next prev parent reply other threads:[~2015-07-22 14: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
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 [this message]
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=1437576912.3484.8.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.