Re: [PATCH v3] soc: qcom: icc-bwmon: Update zone1_thres_count to 3
From: Krzysztof Kozlowski
Date: Tue Mar 17 2026 - 03:13:31 EST
On 17/03/2026 06:45, Pushpendra Singh wrote:
>
> On 2/28/2026 3:19 PM, Krzysztof Kozlowski wrote:
>> On 27/02/2026 12:10, Pushpendra Singh wrote:
>>> From: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx>
>>>
>>> Reduce zone1_thres_count from 16 to 3 so the driver can lower the bus
>>> vote after 3 sample windows instead of waiting for 16. The previous
>>> 16‑window delay (~64 ms) is too long at higher FPS workloads,
>>> causing delayed decision making and measurable power regression.
>>>
>>> Empirical tuning showed that lower values (e.g., 2) made bwmon behavior
>>> jittery, while higher values (4–6) were stable but less responsive and
>>> reduced power savings. A value of 3 provided the best balance: responsive
>>> enough for timely power reduction while maintaining stable bwmon
>>> operation.
>>>
>>> Significant power savings were observed across multiple use cases when
>>> reducing the threshold from 16 to 3:
>>>
>>> USECASE zone1_thres_count=16 zone1_thres_count=3
>>> 4K video playback 236.15 mA 203.15 mA
>>> Sleep 7mA 6.9mA
>>> Display (idle display) 71.95mA 67.11mA
>> Which hardware exactly? Which kernel?
>>
>> You keep running this on downstream, like a lot of code from Qualcomm
>> and speeches on conferences, so I just don't trust the numbers.
>
> The numbers presented were obtained on then upstream 6.6 based kernels across multiple SoCs (sc7280/sa8775p).
So sorry, that is 2.5 years old kernel.
> Also, please suggest benchmarks and other perf level measurements done when the number 16 was chosen initially,
> that way we can ensure there is no regression.
You must run pure upstream code. As I said, I don't care about any
solutions, measurements or improvements based on your downstream fork.
Best regards,
Krzysztof