All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Marco Crivellari <marco.crivellari@suse.com>
Cc: linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH v4 1/3] Workqueue: add system_percpu_wq and system_dfl_wq
Date: Fri, 13 Jun 2025 15:05:40 +0200	[thread overview]
Message-ID: <aEwiJIG0TD7P7oYk@localhost.localdomain> (raw)
In-Reply-To: <20250612133335.788593-2-marco.crivellari@suse.com>

Le Thu, Jun 12, 2025 at 03:33:33PM +0200, Marco Crivellari a écrit :
> Currently if a user enqueue a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
> 
> This lack of consistentcy cannot be addressed without refactoring the API.
> 
> system_wq is a per-CPU worqueue, yet nothing in its name tells about that
> CPU affinity constraint, which is very often not required by users. Make
> it clear by adding a system_percpu_wq.
> 
> system_unbound_wq should be the default workqueue so as not to enforce
> locality constraints for random work whenever it's not required.
> 
> Adding system_dfl_wq to encourage its use when unbound work should be used.
> 
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
>  include/linux/workqueue.h | 8 +++++---
>  kernel/workqueue.c        | 4 ++++
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 6e30f275da77..502ec4a5e32c 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -427,7 +427,7 @@ enum wq_consts {
>  /*
>   * System-wide workqueues which are always present.
>   *
> - * system_wq is the one used by schedule[_delayed]_work[_on]().
> + * system_percpu_wq is the one used by schedule[_delayed]_work[_on]().
>   * Multi-CPU multi-threaded.  There are users which expect relatively
>   * short queue flush time.  Don't queue works which can run for too
>   * long.
> @@ -438,7 +438,7 @@ enum wq_consts {
>   * system_long_wq is similar to system_wq but may host long running
>   * works.  Queue flushing might take relatively long.
>   *
> - * system_unbound_wq is unbound workqueue.  Workers are not bound to
> + * system_dfl_wq is unbound workqueue.  Workers are not bound to
>   * any specific CPU, not concurrency managed, and all queued works are
>   * executed immediately as long as max_active limit is not reached and
>   * resources are available.
> @@ -455,10 +455,12 @@ enum wq_consts {
>   * system_bh[_highpri]_wq are convenience interface to softirq. BH work items
>   * are executed in the queueing CPU's BH context in the queueing order.
>   */
> -extern struct workqueue_struct *system_wq;
> +extern struct workqueue_struct *system_wq; /* use system_percpu_wq, this will be removed */
> +extern struct workqueue_struct *system_percpu_wq;
>  extern struct workqueue_struct *system_highpri_wq;
>  extern struct workqueue_struct *system_long_wq;
>  extern struct workqueue_struct *system_unbound_wq;
> +extern struct workqueue_struct *system_dfl_wq;
>  extern struct workqueue_struct *system_freezable_wq;
>  extern struct workqueue_struct *system_power_efficient_wq;
>  extern struct workqueue_struct *system_freezable_power_efficient_wq;
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 97f37b5bae66..7a3f53a9841e 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -505,12 +505,16 @@ static struct kthread_worker *pwq_release_worker __ro_after_init;
>  
>  struct workqueue_struct *system_wq __ro_after_init;
>  EXPORT_SYMBOL(system_wq);
> +struct workqueue_struct *system_percpu_wq __ro_after_init;
> +EXPORT_SYMBOL(system_percpu_wq);
>  struct workqueue_struct *system_highpri_wq __ro_after_init;
>  EXPORT_SYMBOL_GPL(system_highpri_wq);
>  struct workqueue_struct *system_long_wq __ro_after_init;
>  EXPORT_SYMBOL_GPL(system_long_wq);
>  struct workqueue_struct *system_unbound_wq __ro_after_init;
>  EXPORT_SYMBOL_GPL(system_unbound_wq);
> +struct workqueue_struct *system_dfl_wq __ro_after_init;
> +EXPORT_SYMBOL_GPL(system_dfl_wq);
>  struct workqueue_struct *system_freezable_wq __ro_after_init;
>  EXPORT_SYMBOL_GPL(system_freezable_wq);
>  struct workqueue_struct *system_power_efficient_wq __ro_after_init;

Shouldn't you allocate system_percpu_wq and system_dfl_wq in
workqueue_init_early() ?

And yes I think we should allocate them and not make them a pointer to
system_wq and system_unbound_wq, this way you can more easily
warn deprecated uses of system_wq and system_unbound_wq in the future
after upcoming merge windows.

Thanks.

> -- 
> 2.49.0
> 

-- 
Frederic Weisbecker
SUSE Labs

  reply	other threads:[~2025-06-13 13:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 13:33 [PATCH v4 0/3] Workqueue: add WQ_PERCPU, system_dfl_wq and system_percpu_wq Marco Crivellari
2025-06-12 13:33 ` [PATCH v4 1/3] Workqueue: add system_percpu_wq and system_dfl_wq Marco Crivellari
2025-06-13 13:05   ` Frederic Weisbecker [this message]
2025-06-13 13:19     ` Marco Crivellari
2025-06-12 13:33 ` [PATCH v4 2/3] Workqueue: add new WQ_PERCPU flag Marco Crivellari
2025-06-12 13:33 ` [PATCH v4 3/3] [Doc] Workqueue: add WQ_PERCPU Marco Crivellari
2025-06-13 13:13   ` Frederic Weisbecker
2025-06-13 13:23     ` Marco Crivellari

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=aEwiJIG0TD7P7oYk@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.crivellari@suse.com \
    --cc=mhocko@suse.com \
    --cc=tglx@linutronix.de \
    --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.