From: Thomas Gleixner <tglx@linutronix.de>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: "Tejun Heo" <tj@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Wanpeng Li" <wanpeng.li@hotmail.com>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>
Subject: Re: [PATCH] workqueue: fix rebind bound workers warning
Date: Wed, 11 May 2016 09:34:18 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1605110919340.3540@nanos> (raw)
In-Reply-To: <CANRm+CxCivVhmqO-G=8ZivgE0-EzNRf8izdLMDWRmpLwWOYP+g@mail.gmail.com>
On Wed, 11 May 2016, Wanpeng Li wrote:
> Hi Tejun,
> 2016-05-10 5:50 GMT+08:00 Wanpeng Li <kernellwp@gmail.com>:
> > Cc Thomas, the new state machine author,
> > 2016-05-10 1:00 GMT+08:00 Tejun Heo <tj@kernel.org>:
> >> Hello,
> >>
> >> On Thu, May 05, 2016 at 09:41:31AM +0800, Wanpeng Li wrote:
> >>> The boot CPU handles housekeeping duty(unbound timers, workqueues,
> >>> timekeeping, ...) on behalf of full dynticks CPUs. It must remain
> >>> online when nohz full is enabled. There is a priority set to every
> >>> notifier_blocks:
> >>>
> >>> workqueue_cpu_up > tick_nohz_cpu_down > workqueue_cpu_down
> >>>
> >>> So tick_nohz_cpu_down callback failed when down prepare cpu 0, and
> >>> notifier_blocks behind tick_nohz_cpu_down will not be called any
> >>> more, which leads to workers are actually not unbound. Then hotplug
> >>> state machine will fallback to undo and online cpu 0 again. Workers
> >>> will be rebound unconditionally even if they are not unbound and
> >>> trigger the warning in this progress.
> >>
> >> I'm a bit confused. Are you saying that the hotplug statemachine may
> >> invoke CPU_DOWN_FAILED w/o preceding CPU_DOWN on the same callback?
> >
> > I think so. CPU_DOWN_FAILED is detected in the process of CPU_DOWN_PREPARE
Well, no. It's not detected.
If a down prepare callback fails, then DOWN_FAILED is invoked for all
callbacks which have successfully executed DOWN_PREPARE.
But, workqueue has actually two notifiers. One which handles
UP/DOWN_FAILED/ONLINE and one which handles DOWN_PREPARE.
Now look at the priorities of those callbacks:
CPU_PRI_WORKQUEUE_UP = 5
CPU_PRI_WORKQUEUE_DOWN = -5
So the call order on DOWN_PREPARE is:
CB 1
CB ...
CB workqueue_up() -> Ignores DOWN_PREPARE
CB ...
CB X ---> Fails
So we call up to CB X with DOWN_FAILED
CB 1
CB ...
CB workqueue_up() -> Handles DOWN_FAILED
CB ...
CB X-1
So the problem is that the workqueue stuff handles DOWN_FAILED in the up
callback, while it should do it in the down callback. Which is not a good idea
either because it wants to be called early on rollback...
Brilliant stuff, isn't it? The hotplug rework will solve this problem because
the callbacks become symetric, but for the existing mess, we need some
workaround in the workqueue code.
Thanks,
tglx
next prev parent reply other threads:[~2016-05-11 7:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 1:41 Wanpeng Li
2016-05-09 7:28 ` Wanpeng Li
2016-05-09 17:00 ` Tejun Heo
2016-05-09 21:50 ` Wanpeng Li
2016-05-09 22:14 ` Wanpeng Li
2016-05-10 23:23 ` Wanpeng Li
2016-05-11 7:34 ` Thomas Gleixner [this message]
2016-05-11 8:05 ` Wanpeng Li
2016-05-11 10:03 ` Thomas Gleixner
2016-05-11 10:21 ` Wanpeng Li
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=alpine.DEB.2.11.1605110919340.3540@nanos \
--to=tglx@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=kernellwp@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=wanpeng.li@hotmail.com \
/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®