Re: [PATCH v2 09/13] sched/qos: Add rampup multiplier QoS

["zhidao su (Xiaomi)" <soolaugust@gmail.com>]

Hi Qais,

I did a bit of testing on an Android device running
6.18.20-android17 with UTIL_EST and UTIL_EST_RAMPUP_ZERO enabled, and
sched_qos_default_rampup_multiplier=0.

At the scheduler level, the behaviour looks as expected.  With
rampup_multiplier=0, the worker's se.avg.util_est stayed at 0 in my
runs.  With rampup_multiplier=4, util_est became non-zero immediately in
the high phase and reached ~1023.

For end-to-end behaviour, I could not get a useful signal from longer
steady CPU-bound phases.  q0 tends to catch up via util_avg quickly, and
the result is very sensitive to the frequency state at the start of the
high phase.

The clearest signal I saw was with a synthetic low-periodic ->
short-burst native workload:

  low:  periodic short work + sleep
  high: 5 CPU-bound cycles, no sleep

Each q0/q4 case was gated to start from <= 940800 kHz on CPU4, and the
worker set and verified the QoS value in the worker thread.

In that setup, q4 was faster at the 5th high-cycle in 7/8 paired runs.
The larger wins also matched q4 reaching a higher sampled CPU frequency
during the burst, e.g.

  rep3: q0 691200 -> q4 1344000, c5 delta -41.9 ms
  rep5: q0 691200 -> q4 3398400, c5 delta -79.2 ms
  rep6: q0 691200 -> q4 1344000, c5 delta -91.9 ms

The main negative case was consistent with the sampled frequency state
too:

  rep1: q0 2083200 -> q4 816000, c5 delta +34.1 ms

So this is only a synthetic transition-workload data point, but it does
look consistent with the intended periodic-to-busy transition case.  I
would not interpret it as a general app benchmark result.

No Tested-by tag from me for now, since this is not broad performance
validation.

Thanks,
Zhidao