Re: [PATCH -tip V3 3/8] workqueue: introduce wq_online_cpumask

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Jan 05, 2021 at 04:23:44PM +0800, Lai Jiangshan wrote:

> Even with the help of wq_online_cpumask, the patchset can't silence
> the warning in __set_cpus_allowed_ptr() in this case.  It is indeed
> hard to suppress the warning for unbound pools.  Maybe we need something
                                   ^^^^^^^

Argh.. I forgot about the distinction between bound and unbound again.

> like this (outmost callback of CPUHP_AP_WORKQUEUE_UNBOUND_ONLINE,
> so that workqueue can do preparation when offlining before AP_ACTIVE):
> 
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 0042ef362511..ac2103deb20b 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -20,6 +20,9 @@
>   *               |                               ^
>   *               v                               |
>   *              AP_ACTIVE                      AP_ACTIVE
> + *               |                               ^
> + *               v                               |
> + *              ONLINE                         ONLINE
>   */
> 
>  enum cpuhp_state {
> @@ -194,6 +197,7 @@ enum cpuhp_state {
>         CPUHP_AP_X86_HPET_ONLINE,
>         CPUHP_AP_X86_KVM_CLK_ONLINE,
>         CPUHP_AP_ACTIVE,
> +       CPUHP_AP_WORKQUEUE_UNBOUND_ONLINE,
>         CPUHP_ONLINE,
>  };

Yes, doing the unbound things late should not be a problem.

> The other way is to modify __set_cpus_allowed_ptr() to suppress the
> warning for kworkers and believe/let the workqueue handle cpumask correctly.

The thing is that we don't want 'random' work injected in the CPU during
the hotplug process since we're not exactly sure what state the thing is
in. Once we're active, we know all is well and we can run regular crud.

The thing with bound workers is that they'll only run work originating
on the CPU itself, and should thus be fine.