All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 24 Jul 2015 05:38:59 +0200	[thread overview]
Message-ID: <1437709139.3520.73.camel@gmail.com> (raw)
In-Reply-To: <20150722152500.GN15934@mtj.duckdns.org>

On Wed, 2015-07-22 at 11:25 -0400, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jul 22, 2015 at 05:19:00PM +0200, Mike Galbraith wrote:
> > Ew, looking at the numbers, they may prefer to either a) pretend to not
> > notice, or b) scurry off to HPC'R'US store if a) won't fly ;-)
> 
> Yeah, there are a lot of them.  The sad part is that only very few of
> them would actually need local binding for correctness. :(

I'm going to end this thread with an under my breath mutter.  Before I
do that, note that I went and beat up three different boxen over days
before turning trivial little patchlet loose, ie I was quite paranoid
despite the below, "No way Jose" was not entirely unexpected.

Mutter: WORK_CPU_UNBOUND is about as far from a local execution
guarantee as it gets, and not only is it prominently displayed for all
to see...

/**
 * queue_work - queue work on a workqueue
 * @wq: workqueue to use
 * @work: work to queue
 *
 * Returns %false if @work was already on a queue, %true otherwise.
 *
 * We queue the work to the CPU on which it was submitted, but if the CPU dies
 * it can be processed by another CPU.
 */
static inline bool queue_work(struct workqueue_struct *wq,
                              struct work_struct *work)
{
        return queue_work_on(WORK_CPU_UNBOUND, wq, work);
}

...there's nothing ambiguous about that.  While it states that we queue
locally, it also clearly states that local execution is NOT guaranteed,
making assumption thereof a BUG, which in turn makes it seem a bit odd
to tie fixing up nohz_full a little to auditing and fixing every booboo
ever made (unlikely to ever happen).  It would appear that the only way
anyone could ever have sanely assume local execution, WORK_CPU_UNBOUND
aside, is to have called get_online_cpus() before queueing any work.

Mutter expressed, it's not a big hairy deal, anyone using an SMP kernel
with an expectation of zero perturbation is doomed to be disappointed
anyway, patchlet just reduced noise a bit.

	-Mike (mutter mutter mutter;)


      reply	other threads:[~2015-07-24  3:39 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
2015-07-22 15:19                     ` Mike Galbraith
2015-07-22 15:25                       ` Tejun Heo
2015-07-24  3:38                         ` Mike Galbraith [this message]

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=1437709139.3520.73.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.