From: Mark Brown <broonie@kernel.org>
Date: Mon, 11 May 2026 00:52:53 +0000 (+0900)
Subject: ASoC: Move system_long_wq to system_dfl_long_wq
X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=e3cc335cdcd5715427864791514c5d28a2ede884;p=thirdparty%2Fkernel%2Flinux.git

ASoC: Move system_long_wq to system_dfl_long_wq

Marco Crivellari <marco.crivellari@suse.com> says:

Currently the code uses the per-cpu workqueue system_long_wq to schedule
long running works.

Unbound works could benefit from scheduler task placement, to optimize
performance and power consumption. Another good reason to have this unbound,
is the "queue_delayed_work()" function, used to enqueue the work item.
More details on this will follow in the next section.

Recently, a new unbound workqueue specific for long running work has been
added:

    c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")

~~~ Details about queue_delayed_work ~~~

system_long_wq is a per-cpu workqueue and it is used as a parameter of
queue_delayed_work(). This function schedule an item that it will later
be enqueued (once the timer will fire). __queue_delayed_work() does the job
receiving as "cpu" WORK_CPU_UNBOUND:

    if (housekeeping_enabled(HK_TYPE_TIMER)) {
    //      [....]
    } else {
            if (likely(cpu == WORK_CPU_UNBOUND))
                    add_timer_global(timer);
            else
                    add_timer_on(timer, cpu);
    }

The timer is global, so can fire everywhere, and the work item will be
enqueued where the timer fired.

Since the workqueue work doesn't rely on per-cpu variables, there is no
obvious reason that justify the use of a per-cpu workqueue. So change the
workqueue with the new system_dfl_long_wq, so that the used workqueue is
now unbound and can benefit from scheduler task placement.
---

e3cc335cdcd5715427864791514c5d28a2ede884