From: Shivnandan Kumar <quic_kshivnan@quicinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<quic_rgottimu@quicinc.com>
Subject: Re: [PATCH] soc: qcom: icc-bwmon: Update zone1_thres_count to 3
Date: Wed, 22 May 2024 14:35:21 +0530 [thread overview]
Message-ID: <baa55c1f-2670-4a3c-abcf-ea4e841e4a1e@quicinc.com> (raw)
In-Reply-To: <bc973b4f-fe8b-44e5-afbc-f3ce8a6fc873@linaro.org>
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
>
next prev parent reply other threads:[~2024-05-22 9:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 8:15 Shivnandan Kumar
2024-05-22 8:28 ` Krzysztof Kozlowski
2024-05-22 9:05 ` Shivnandan Kumar [this message]
2024-05-22 9:19 ` Krzysztof Kozlowski
2024-05-22 16:57 ` Bjorn Andersson
2025-08-13 4:53 ` Pushpendra Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=baa55c1f-2670-4a3c-abcf-ea4e841e4a1e@quicinc.com \
--to=quic_kshivnan@quicinc.com \
--cc=andersson@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_rgottimu@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®