From: Thara Gopinath <thara.gopinath@linaro.org>
To: Steev Klimaszewski <steev@kali.org>, Lukasz Luba <lukasz.luba@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, sudeep.holla@arm.com,
will@kernel.org, catalin.marinas@arm.com, linux@armlinux.org.uk,
gregkh@linuxfoundation.org, rafael@kernel.org,
viresh.kumar@linaro.org, amitk@kernel.org,
daniel.lezcano@linaro.org, amit.kachhap@gmail.com,
bjorn.andersson@linaro.org, agross@kernel.org
Subject: Re: [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication
Date: Fri, 5 Nov 2021 17:06:26 -0400 [thread overview]
Message-ID: <b7e76c2a-ceac-500a-ff75-535a3f0d51d6@linaro.org> (raw)
In-Reply-To: <74603569-2ff1-999e-9618-79261fdb0ee4@kali.org>
On 11/5/21 3:51 PM, Steev Klimaszewski wrote:
>
> On 11/5/21 2:18 PM, Thara Gopinath wrote:
>>
>>
>> On 11/5/21 1:33 PM, Steev Klimaszewski wrote:
>>> Hi,
>>>
>>> On 11/5/21 11:26 AM, Lukasz Luba wrote:
>>>> Hi Steev,
>>>>
>>>> On 11/5/21 3:39 PM, Steev Klimaszewski wrote:
>>>>> Hi Lukasz,
>>>>>
>>>> [snip]
>> Hi Steve,
>>
>> Does your system have enough load to hit the boost frequencies ? I
>> don't think this patch should affect hitting boost frequencies as
>> there is no error being returned from topology_update_thermal_pressure.
>>
>> The warning you are getting is because you have boost frequency
>> enabled and IIUC lmh enabled and thermal pressure framework bails out
>> due to boost_frequency being greater than what is available in per_cpu
>> freq_factor. This is because we do not recalculate freq_factor every
>> time boost is enabled / disabled. IIRC there were some discussions
>> around rebuilding scheduler domains and capacity with user space
>> changes to max frequency but it has never proceeded much. Till that
>> point, I think the right way, is to check whether the new capcity
>> exceeds the max_capacity of the cpu and if yes use max_capacity in
>> lieu of new_capacity to calculate thermal pressure.
>>
> Hi Thara,
>
> I should definitely be able to push it to 2.96GHz, however I'm simply
> not getting it at all with these patches applied. >
> So, I'm currently compiling multiple applications - alacritty
> (https://github.com/alacritty/alacritty), and zellij
> (https://github.com/zellij-org/zellij), as well as running pixz on a
> 5.1GB file to compress it, and throwing in cpuburn-a53
> (https://github.com/ssvb/cpuburn-arm) and I'm simply not getting 2.96GHz
> at all. Ever. I don't normally try to push it that high, but I wanted
> to see if we could ever hit it (the system was also never going above 86C)
Hi,
So IIUC the below logs correctly, you are never hitting boost frequency
(with or without this patch series). Is that correct ?
w.r.t temperature , how are you measuring it? Do you have LMh enabled or
are you using tsens to mitigate cpu temperature ?
--
Warm Regards
Thara (She/Her/Hers)
>
> analyzing CPU 4:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:54.84%, 902 MHz:0.02%, 979 MHz:0.02%, 1.06
> GHz:0.02%, 1.21 GHz:0.08%, 1.29 GHz:0.07%, 1.36 GHz:0.09%, 1.46
> GHz:0.04%, 1.54 GHz:0.02%, 1.61 GHz:0.02%, 1.69 GHz:0.02%, 1.77
> GHz:0.13%, 1.84 GHz:0.04%, 1.92 GHz:0.04%, 2.00 GHz:0.02%, 2.09
> GHz:0.03%, 2.17 GHz:0.02%, 2.25 GHz:0.02%, 2.32 GHz:0.01%, 2.40
> GHz:0.02%, 2.48 GHz:0.02%, 2.55 GHz:0.02%, 2.65 GHz:0.02%, 2.75
> GHz:0.02%, 2.84 GHz:44.38%, 2.96 GHz:0.00% (8066)
> analyzing CPU 5:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:54.84%, 902 MHz:0.02%, 979 MHz:0.02%, 1.06
> GHz:0.02%, 1.21 GHz:0.08%, 1.29 GHz:0.07%, 1.36 GHz:0.09%, 1.46
> GHz:0.04%, 1.54 GHz:0.02%, 1.61 GHz:0.02%, 1.69 GHz:0.02%, 1.77
> GHz:0.13%, 1.84 GHz:0.04%, 1.92 GHz:0.04%, 2.00 GHz:0.02%, 2.09
> GHz:0.03%, 2.17 GHz:0.02%, 2.25 GHz:0.02%, 2.32 GHz:0.01%, 2.40
> GHz:0.02%, 2.48 GHz:0.02%, 2.55 GHz:0.02%, 2.65 GHz:0.02%, 2.75
> GHz:0.02%, 2.84 GHz:44.38%, 2.96 GHz:0.00% (8066)
> analyzing CPU 6:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:54.84%, 902 MHz:0.02%, 979 MHz:0.02%, 1.06
> GHz:0.02%, 1.21 GHz:0.08%, 1.29 GHz:0.07%, 1.36 GHz:0.09%, 1.46
> GHz:0.04%, 1.54 GHz:0.02%, 1.61 GHz:0.02%, 1.69 GHz:0.02%, 1.77
> GHz:0.13%, 1.84 GHz:0.04%, 1.92 GHz:0.04%, 2.00 GHz:0.02%, 2.09
> GHz:0.03%, 2.17 GHz:0.02%, 2.25 GHz:0.02%, 2.32 GHz:0.01%, 2.40
> GHz:0.02%, 2.48 GHz:0.02%, 2.55 GHz:0.02%, 2.65 GHz:0.02%, 2.75
> GHz:0.02%, 2.84 GHz:44.38%, 2.96 GHz:0.00% (8066)
> analyzing CPU 7:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:54.84%, 902 MHz:0.02%, 979 MHz:0.02%, 1.06
> GHz:0.02%, 1.21 GHz:0.08%, 1.29 GHz:0.07%, 1.36 GHz:0.09%, 1.46
> GHz:0.04%, 1.54 GHz:0.02%, 1.61 GHz:0.02%, 1.69 GHz:0.02%, 1.77
> GHz:0.13%, 1.84 GHz:0.04%, 1.92 GHz:0.04%, 2.00 GHz:0.02%, 2.09
> GHz:0.03%, 2.17 GHz:0.02%, 2.25 GHz:0.02%, 2.32 GHz:0.01%, 2.40
> GHz:0.02%, 2.48 GHz:0.02%, 2.55 GHz:0.02%, 2.65 GHz:0.02%, 2.75
> GHz:0.02%, 2.84 GHz:44.38%, 2.96 GHz:0.00% (8066)
>
>
>
> After removing this patchset, and rebooting and just compiling zellij:
>
> analyzing CPU 4:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:16.01%, 902 MHz:0.08%, 979 MHz:0.05%, 1.06
> GHz:0.06%, 1.21 GHz:0.37%, 1.29 GHz:0.17%, 1.36 GHz:0.15%, 1.46
> GHz:0.20%, 1.54 GHz:0.18%, 1.61 GHz:0.21%, 1.69 GHz:0.17%, 1.77
> GHz:0.22%, 1.84 GHz:0.32%, 1.92 GHz:0.37%, 2.00 GHz:0.22%, 2.09
> GHz:0.20%, 2.17 GHz:0.20%, 2.25 GHz:0.19%, 2.32 GHz:0.19%, 2.40
> GHz:0.21%, 2.48 GHz:0.18%, 2.55 GHz:0.18%, 2.65 GHz:0.21%, 2.75
> GHz:0.16%, 2.84 GHz:79.49%, 2.96 GHz:0.03% (5315)
> analyzing CPU 5:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:16.01%, 902 MHz:0.08%, 979 MHz:0.05%, 1.06
> GHz:0.06%, 1.21 GHz:0.37%, 1.29 GHz:0.17%, 1.36 GHz:0.15%, 1.46
> GHz:0.20%, 1.54 GHz:0.18%, 1.61 GHz:0.21%, 1.69 GHz:0.17%, 1.77
> GHz:0.22%, 1.84 GHz:0.32%, 1.92 GHz:0.37%, 2.00 GHz:0.22%, 2.09
> GHz:0.20%, 2.17 GHz:0.20%, 2.25 GHz:0.19%, 2.32 GHz:0.19%, 2.40
> GHz:0.21%, 2.48 GHz:0.18%, 2.55 GHz:0.18%, 2.65 GHz:0.21%, 2.75
> GHz:0.16%, 2.84 GHz:79.49%, 2.96 GHz:0.03% (5315)
> analyzing CPU 6:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:16.01%, 902 MHz:0.08%, 979 MHz:0.05%, 1.06
> GHz:0.06%, 1.21 GHz:0.37%, 1.29 GHz:0.17%, 1.36 GHz:0.15%, 1.46
> GHz:0.20%, 1.54 GHz:0.18%, 1.61 GHz:0.21%, 1.69 GHz:0.17%, 1.77
> GHz:0.22%, 1.84 GHz:0.32%, 1.92 GHz:0.37%, 2.00 GHz:0.22%, 2.09
> GHz:0.20%, 2.17 GHz:0.20%, 2.25 GHz:0.19%, 2.32 GHz:0.19%, 2.40
> GHz:0.21%, 2.48 GHz:0.18%, 2.55 GHz:0.18%, 2.65 GHz:0.21%, 2.75
> GHz:0.16%, 2.84 GHz:79.49%, 2.96 GHz:0.03% (5315)
> analyzing CPU 7:
> driver: qcom-cpufreq-hw
> CPUs which run at the same hardware frequency: 4 5 6 7
> CPUs which need to have their frequency coordinated by software: 4 5 6 7
> maximum transition latency: 4294.55 ms.
> hardware limits: 826 MHz - 2.96 GHz
> available frequency steps: 826 MHz, 902 MHz, 979 MHz, 1.06 GHz, 1.21
> GHz, 1.29 GHz, 1.36 GHz, 1.46 GHz, 1.54 GHz, 1.61 GHz, 1.69 GHz, 1.77
> GHz, 1.84 GHz, 1.92 GHz, 2.00 GHz, 2.09 GHz, 2.17 GHz, 2.25 GHz, 2.32
> GHz, 2.40 GHz, 2.48 GHz, 2.55 GHz, 2.65 GHz, 2.75 GHz, 2.84 GHz
> available cpufreq governors: ondemand, conservative, powersave,
> userspace, performance, schedutil
> current policy: frequency should be within 826 MHz and 2.84 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency is 2.84 GHz.
> cpufreq stats: 826 MHz:16.01%, 902 MHz:0.08%, 979 MHz:0.05%, 1.06
> GHz:0.06%, 1.21 GHz:0.37%, 1.29 GHz:0.17%, 1.36 GHz:0.15%, 1.46
> GHz:0.20%, 1.54 GHz:0.18%, 1.61 GHz:0.21%, 1.69 GHz:0.17%, 1.77
> GHz:0.22%, 1.84 GHz:0.32%, 1.92 GHz:0.37%, 2.00 GHz:0.22%, 2.09
> GHz:0.20%, 2.17 GHz:0.20%, 2.25 GHz:0.19%, 2.32 GHz:0.19%, 2.40
> GHz:0.21%, 2.48 GHz:0.18%, 2.55 GHz:0.18%, 2.65 GHz:0.21%, 2.75
> GHz:0.16%, 2.84 GHz:79.49%, 2.96 GHz:0.03% (5315)
>
>
>>>
>>> Thank you for the fast response!
>>>
>>> -- steev
>>>
>>
next prev parent reply other threads:[~2021-11-05 21:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 16:10 [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication Lukasz Luba
2021-11-03 16:10 ` [PATCH v3 1/5] arch_topology: Introduce thermal pressure update function Lukasz Luba
2021-11-03 16:10 ` [PATCH v3 2/5] thermal: cpufreq_cooling: Use new " Lukasz Luba
2021-11-03 16:10 ` [PATCH v3 3/5] cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure Lukasz Luba
2021-11-03 16:10 ` [PATCH v3 4/5] cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function Lukasz Luba
2021-11-05 19:12 ` Thara Gopinath
2021-11-08 14:12 ` Lukasz Luba
2021-11-08 21:23 ` Thara Gopinath
2021-11-09 8:46 ` Lukasz Luba
2021-11-03 16:10 ` [PATCH v3 5/5] arch_topology: Remove unused topology_set_thermal_pressure() and related Lukasz Luba
2021-11-05 15:39 ` [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication Steev Klimaszewski
2021-11-05 16:26 ` Lukasz Luba
2021-11-05 17:33 ` Steev Klimaszewski
2021-11-05 19:18 ` Thara Gopinath
2021-11-05 19:51 ` Steev Klimaszewski
2021-11-05 21:06 ` Thara Gopinath [this message]
2021-11-05 22:46 ` Steev Klimaszewski
2021-11-08 10:44 ` Lukasz Luba
2021-11-08 14:11 ` Thara Gopinath
2021-11-08 15:22 ` Steev Klimaszewski
2021-11-08 21:31 ` Thara Gopinath
2021-11-08 23:21 ` Steev Klimaszewski
2021-11-09 8:29 ` Lukasz Luba
2021-11-09 15:46 ` Steev Klimaszewski
2021-11-09 16:22 ` Lukasz Luba
2021-11-09 18:13 ` Lukasz Luba
2021-11-09 19:09 ` Steev Klimaszewski
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=b7e76c2a-ceac-500a-ff75-535a3f0d51d6@linaro.org \
--to=thara.gopinath@linaro.org \
--cc=agross@kernel.org \
--cc=amit.kachhap@gmail.com \
--cc=amitk@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=steev@kali.org \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.org \
--cc=will@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