[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