[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <baa55c1f-2670-4a3c-abcf-ea4e841e4a1e@quicinc.com>
Date: Wed, 22 May 2024 14:35:21 +0530
From: Shivnandan Kumar <quic_kshivnan@...cinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Bjorn Andersson
<andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>
CC: <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<quic_rgottimu@...cinc.com>
Subject: Re: [PATCH] soc: qcom: icc-bwmon: Update zone1_thres_count to 3
On 5/22/2024 1:58 PM, Krzysztof Kozlowski wrote:
> On 22/05/2024 10:15, Shivnandan Kumar wrote:
>> Update zone1_thres_count to 3 from 16 so that
>> driver can reduce bus vote in 3 sample windows instead
>> of waiting for 16 windows. This is in line with downstream
>> implementation.
>>
>
> This might make bwmon quite jittery. I don't think downstream is the
> source of truth here. Please provide some measurements *on mainline tree*.
>
Hi Krzysztof,
The 16-window (64 ms) waiting time is too long to reduce the bus vote.
At higher FPS, there will be multiple frames in 64ms e.g. 4 frames at
60FPS in 64ms. Hence, delay of 64ms in decision making will lead to
higher power regression. I’ve tested this change for 4K video playback
on mainline tree, and there’s a significant power-saving.
I propose to make it a tunable,so that user space can tune it
based on runtime depending on fps.
USECASE zone1_thres_count=16 zone1_thres_count=3
4K video playback 236.15 mA 203.15 mA
Thanks,
Shivnandan
> Best regards,
> Krzysztof
>
Powered by blists - more mailing lists