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: Mon, 8 Nov 2021 09:11:37 -0500 [thread overview] Message-ID: <59054c90-c1cd-85bf-406e-579df668d7b4@linaro.org> (raw) In-Reply-To: <f955a2aa-f788-00db-1ed8-dc9c7a1b2572@kali.org> On 11/5/21 6:46 PM, Steev Klimaszewski wrote: > >> [snip] >> 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 ? > > > Hi, > > I was wrong - it does indeed go boost with the patchset applied, it's > just that it doesn't boost up to 2.96GHz very often at all. As noted by > the 0.03% when i ran it while compiling zellij; I reapplied the patches > (and the 6th patch from Lukasz's email) and after boot, 2.96GHz was > showing at 0.39%. > > Most tools that read the cpu frequency don't really seem to be well > suited for big.LITTLE, and seem to throw an average of the speed, so > cpufreq-info was the best I have. We're apparently supposed to be using > cpupower these days, but it doesn't seem to know anything about arm64 > devices. > > Temperature wise, I'm just getting from the sensors, and I am using LMh. > > Now, I have to admit, while I've thrown a patch here or there, I'm not > exactly a kernel developer, just enough knowledge to be somewhat > dangerous and know how to backport things. In my mind, and my line of > thinking, I would expect with boost enabled, that the cpu would boost up > to that as often as possible, not require a specific workload to > actually hit it. But then again, I would expect multiple compilation > jobs to be one of the workloads that would? Hi Steev, So this depends on the cpufreq governor you are using. By-default arm systems have sched-util governor enabled. This means you will scale up to boost depending on cpu load and not always. If you want to ensure you are always hitting boost frequency, you should enable performance governor for cpufreq and try. Also since the defconfig has by default CPU_FREQ_STAT enabled, you should be able to get statistics out of cpufreq to see the time spent by a cpu in each frequency. I think cpufreq-info -s should give you this info. If not, you can explicitly get it for each cpu from cat /sys/devices/system/cpu/cpu<X>/cpufreq/stats/time_in_state Regarding temperature, if you have applied all the patches in the sdm845 LMh series and have LMh enabled, cpu throttling starts around 95 degree C. > > So I think, the part about never hitting 2.96GHz can be dismissed, and > was simply my lack of knowledge about the cpufreq-info tool's averages. > It does seem however to rarely ever hit 2.96GHz and I would actually > expect it to hit it far more often. > -- Warm Regards Thara (She/Her/Hers)
WARNING: multiple messages have this Message-ID (diff)
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: Mon, 8 Nov 2021 09:11:37 -0500 [thread overview] Message-ID: <59054c90-c1cd-85bf-406e-579df668d7b4@linaro.org> (raw) In-Reply-To: <f955a2aa-f788-00db-1ed8-dc9c7a1b2572@kali.org> On 11/5/21 6:46 PM, Steev Klimaszewski wrote: > >> [snip] >> 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 ? > > > Hi, > > I was wrong - it does indeed go boost with the patchset applied, it's > just that it doesn't boost up to 2.96GHz very often at all. As noted by > the 0.03% when i ran it while compiling zellij; I reapplied the patches > (and the 6th patch from Lukasz's email) and after boot, 2.96GHz was > showing at 0.39%. > > Most tools that read the cpu frequency don't really seem to be well > suited for big.LITTLE, and seem to throw an average of the speed, so > cpufreq-info was the best I have. We're apparently supposed to be using > cpupower these days, but it doesn't seem to know anything about arm64 > devices. > > Temperature wise, I'm just getting from the sensors, and I am using LMh. > > Now, I have to admit, while I've thrown a patch here or there, I'm not > exactly a kernel developer, just enough knowledge to be somewhat > dangerous and know how to backport things. In my mind, and my line of > thinking, I would expect with boost enabled, that the cpu would boost up > to that as often as possible, not require a specific workload to > actually hit it. But then again, I would expect multiple compilation > jobs to be one of the workloads that would? Hi Steev, So this depends on the cpufreq governor you are using. By-default arm systems have sched-util governor enabled. This means you will scale up to boost depending on cpu load and not always. If you want to ensure you are always hitting boost frequency, you should enable performance governor for cpufreq and try. Also since the defconfig has by default CPU_FREQ_STAT enabled, you should be able to get statistics out of cpufreq to see the time spent by a cpu in each frequency. I think cpufreq-info -s should give you this info. If not, you can explicitly get it for each cpu from cat /sys/devices/system/cpu/cpu<X>/cpufreq/stats/time_in_state Regarding temperature, if you have applied all the patches in the sdm845 LMh series and have LMh enabled, cpu throttling starts around 95 degree C. > > So I think, the part about never hitting 2.96GHz can be dismissed, and > was simply my lack of knowledge about the cpufreq-info tool's averages. > It does seem however to rarely ever hit 2.96GHz and I would actually > expect it to hit it far more often. > -- Warm Regards Thara (She/Her/Hers) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-08 14:11 UTC|newest] Thread overview: 54+ 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 ` 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 ` Lukasz Luba 2021-11-03 16:10 ` [PATCH v3 2/5] thermal: cpufreq_cooling: Use new " Lukasz Luba 2021-11-03 16:10 ` 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 ` 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-03 16:10 ` Lukasz Luba 2021-11-05 19:12 ` Thara Gopinath 2021-11-05 19:12 ` Thara Gopinath 2021-11-08 14:12 ` Lukasz Luba 2021-11-08 14:12 ` Lukasz Luba 2021-11-08 21:23 ` Thara Gopinath 2021-11-08 21:23 ` Thara Gopinath 2021-11-09 8:46 ` Lukasz Luba 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-03 16:10 ` Lukasz Luba 2021-11-05 15:39 ` [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication Steev Klimaszewski 2021-11-05 15:39 ` Steev Klimaszewski 2021-11-05 16:26 ` Lukasz Luba 2021-11-05 16:26 ` Lukasz Luba 2021-11-05 17:33 ` Steev Klimaszewski 2021-11-05 17:33 ` Steev Klimaszewski 2021-11-05 19:18 ` Thara Gopinath 2021-11-05 19:18 ` Thara Gopinath 2021-11-05 19:51 ` Steev Klimaszewski 2021-11-05 19:51 ` Steev Klimaszewski 2021-11-05 21:06 ` Thara Gopinath 2021-11-05 21:06 ` Thara Gopinath 2021-11-05 22:46 ` Steev Klimaszewski 2021-11-05 22:46 ` Steev Klimaszewski 2021-11-08 10:44 ` Lukasz Luba 2021-11-08 10:44 ` Lukasz Luba 2021-11-08 14:11 ` Thara Gopinath [this message] 2021-11-08 14:11 ` Thara Gopinath 2021-11-08 15:22 ` Steev Klimaszewski 2021-11-08 15:22 ` Steev Klimaszewski 2021-11-08 21:31 ` Thara Gopinath 2021-11-08 21:31 ` Thara Gopinath 2021-11-08 23:21 ` Steev Klimaszewski 2021-11-08 23:21 ` Steev Klimaszewski 2021-11-09 8:29 ` Lukasz Luba 2021-11-09 8:29 ` Lukasz Luba 2021-11-09 15:46 ` Steev Klimaszewski 2021-11-09 15:46 ` Steev Klimaszewski 2021-11-09 16:22 ` Lukasz Luba 2021-11-09 16:22 ` Lukasz Luba 2021-11-09 18:13 ` Lukasz Luba 2021-11-09 18:13 ` Lukasz Luba 2021-11-09 19:09 ` Steev Klimaszewski 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=59054c90-c1cd-85bf-406e-579df668d7b4@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.