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

["Chung-Kai (Michael) Mei" <chungkai@google.com>]

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, would exposing pm_wq
with WQ_SYSFS (so platforms that need it can tune
/sys/devices/virtual/workqueue/pm/nice) be a cleaner alternative?

Best regards,
Chungkai