From: Pushpendra Singh <pushpendra.singh@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] soc: qcom: icc-bwmon: Update zone1_thres_count to 3
Date: Thu, 5 Nov 2026 13:16:17 +0530 [thread overview]
Message-ID: <14d9e262-c3e6-41b4-a408-3d12185b0d48@oss.qualcomm.com> (raw)
In-Reply-To: <7a92ca6c-cc66-486f-b297-cb2907e1c0e6@oss.qualcomm.com>
On 6/16/2026 5:09 PM, Konrad Dybcio wrote:
> On 2/27/26 12:10 PM, Pushpendra Singh wrote:
>> From: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>>
>> 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
>>
>> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com>
>> Signed-off-by: Pushpendra Singh <pussin@qti.qualcomm.com>
>> ---
>
> Since this patch does not seem to be moving on its own, I will gladly
> hijack the discussion..
>
> I was wondering if we could transplant the bwmon devfreq+governor+memlat
> setup from downstream. It seems to be way "smarter", in the sense that
> it keeps some hysteresis information, unlike icc-bwmon, which is purely
> reactive to immediate signals, in addition to (in my brief understanding)
> sampling other data sources, such as the PMU
>
Thanks for the suggestion.The downstream solution explores a broader policy space with additional inputs and hysteresis. It is an interesting direction, though evaluating such an approach would likely be a separate discussion.
For this series, we are focusing on a small tuning of the existing icc-bwmon behavior. Based on our latest validation, reducing zone1_thres_count improves responsiveness to decreasing bandwidth demand, allowing DDR and LLCC votes to be reduced sooner and resulting in measurable power savings.
Thanks,
Pushpendra
prev parent reply other threads:[~2026-11-05 7:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 11:10 Pushpendra Singh
2026-02-27 19:57 ` Dmitry Baryshkov
2026-02-28 9:49 ` Krzysztof Kozlowski
2026-03-17 5:45 ` Pushpendra Singh
2026-03-17 7:13 ` Krzysztof Kozlowski
2026-03-17 15:36 ` Dmitry Baryshkov
2026-11-05 7:46 ` Pushpendra Singh
2026-06-16 11:39 ` Konrad Dybcio
2026-11-05 7:46 ` Pushpendra Singh [this message]
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=14d9e262-c3e6-41b4-a408-3d12185b0d48@oss.qualcomm.com \
--to=pushpendra.singh@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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®