[PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication

Steev Klimaszewski steev at kali.org
Fri Nov 5 15:46:25 PDT 2021


> [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?

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.




More information about the linux-arm-kernel mailing list