[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a623910-0fce-4835-a047-4086dafd3186@linaro.org>
Date: Wed, 22 May 2024 11:19:42 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Shivnandan Kumar <quic_kshivnan@...cinc.com>,
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 22/05/2024 11:05, Shivnandan Kumar wrote:
>
>
> 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.
Please include it, with measurement below, in the commit msg.
> 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
>>
Best regards,
Krzysztof
Powered by blists - more mailing lists