Re: [PATCH] PM: runtime: Allocate pm_wq with WQ_HIGHPRI

[Rafael J. Wysocki (Intel)]

On Mon, Nov 2, 2026 at 5:03 AM Chung-Kai (Michael) Mei
<chungkai@xxxxxxxxxx> wrote:
>
> On Tue, Oct 27, 2026 at 11:59 AM Rafael J. Wysocki wrote:
> > Interesting.
> >
> > I suppose that there is a measurable performance benefit from this
> > change, so it would be good to say what it is (say, an increased frame
> > rate or similar).
>
> Below is A/B data from two arm64 Android phones (6.12-based kernels)
> comparing unbound pm_wq at nice 0 vs. WQ_HIGHPRI (nice -20), with this
> patch as the only difference.
>
> The workload is an automated UI test that repeatedly swipes open and
> collapses the notification shade on a 120 Hz display, driving frequent
> GPU and display runtime PM suspend/resume transitions alongside active
> frame composition:
>
>   Platform A: 8 CPUs, 245 vs. 245 runs (220,524 vs. 217,954 work items)
>   ---------------------------------------------------------------------
>   pm_runtime_work CPU wait mean    151.0 -> 107.5 us        (-28.8%)
>   pm_runtime_work CPU wait P99     1,867 -> 1,102 us        (-41.0%)
>   pm_runtime_work CPU wait max     15.08 -> 5.77 ms         (-61.7%)
>   pm_runtime_work wait >= 2 ms/run  7.51 -> 0.94            (-87.5%)
>   pm_runtime_work wait >= 5 ms/run 0.457 -> 0.008           (-98.2%)
>   UI rpm_resume() waker wait P90   662.7 -> 156.7 us        (-76.4%)
>   UI rpm_resume() D-state P90      717.4 -> 213.7 us        (-70.2%)
>   FrameTimeline app missed/run     0.204 -> 0.171           (-16.0%)
>   FrameTimeline SF missed/run      1.086 -> 1.074           (-1.1%)
>
>   Platform B: 7 CPUs, 196 vs. 245 runs (85,957 vs. 104,452 work items)
>   ---------------------------------------------------------------------
>   pm_runtime_work CPU wait mean    134.5 -> 100.9 us        (-25.0%)
>   pm_runtime_work CPU wait P99     1,809 -> 1,122 us        (-38.0%)
>   pm_runtime_work CPU wait max     15.77 -> 3.71 ms         (-76.5%)
>   pm_runtime_work wait >= 2 ms/run  3.40 -> 0.53            (-84.5%)
>   pm_runtime_work wait >= 5 ms/run 0.189 -> 0.000          (-100.0%)
>   UI rpm_resume() waker wait P90   207.5 -> 23.3 us         (-88.8%)
>   UI rpm_resume() D-state P90      217.1 -> 73.3 us         (-66.2%)
>   FrameTimeline SF missed/run      0.551 -> 0.531           (-3.7%)
>
> > Essentially, we're talking about redistributing CPU time between
> > tasks, so some tasks will get more latency as a result of this change,
> > which means that it is not an obviously right thing to do.
>
> Agreed, this is a scheduling trade-off: pm_wq runs arbitrary driver
> callbacks and genpd work whose cost is driver- and platform-dependent,
> so the impact on other tasks cannot be assumed negligible across all
> systems.
>
> If changing the global default is undesirable,

I'm not saying it's undesirable, I'm just saying that there could be
more analysis of its impact IMV.

The FrameTimeline numbers don't seem to be changing significantly
although there is measurable improvement.

What about other workloads?  Are they affected in any way and if so then how?

> would exposing pm_wq
> with WQ_SYSFS (so platforms that need it can tune
> /sys/devices/virtual/workqueue/pm/nice) be a cleaner alternative?

I'm not a big fan of this TBH.