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

[Qais Yousef]

On 06/18/26 16:30, zhidao su (Xiaomi) wrote:
> 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 for the running the tests. IIUC, you're reporting that all is good so
far.