[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1038981: capping maximum frequency no longer works in kernel 6.1



On Tuesday, 1 August 2023 01:39:50 CEST AlMa wrote:
> > I don't want to be an ass, but why didn't you do such elementary research
> > before filing a bug report?
> 
> the fact that you searched for exactly "powersave frequency governor"

From your initial message: "The governor is powersave everywhere."
So it wasn't based on some inside/expert knowledge of the problem domain, I 
just put what you said in a search engine.
I just tried searching for "powersave governor" and the arch wiki page was 
even higher in the result list ...

> and “Intel p-state” (and NOT something else) is elementary to YOU.  

Searching for "Intel p-state" was based on what I read in the arch wiki ...

> I saw the Archlinux page but was (and still am) unsure of how much of what
> is said there applies to Debian.  Heaven knows how differently you and them
> configure the kernels (and surely you and them don't take exactly the same
> kernels anyway).

As I also explained earlier, that page contains the following line:
"Both Intel and AMD define a way to have the CPU decide its own speed"
from the section "Autonomous frequency scaling" which leads to the conclusion 
the the CPU *hardware* itself determines its own speed.

Kernel configuration is different, but your suggestion that we may not both be 
using the same source, is just weird. And easily refuted by a simple search.

> As for
> https://www.kernel.org/doc/html/v6.1/admin-guide/pm/intel_pstate.html ,
> it's dated 2017 (and no later year is mentioned!), whereas the processor
> in #1038981 is from Q2'20, and the kernel is from 2023 (6 years later
> than the document date).  So even if I had found that document myself, I
> might have dismissed it just based on date.

The "Autonomous frequency scaling" section states:
"intel-pstate is set to "active" and hardware P-state (HWP) is available (i.e. 
Sandy Bridge and newer)"

Searching for "Sandy Bridge" shows that technology is available since 2011...

If it's available in the 6.1 documentation, it applies to the 6.1 kernel.
I added "Update version number to 6.1" as in another 'bug' you linked to 
version 4.12 for kernel parameters and was meant as a hint to look in 
documentation for the correct kernel version. 

The copyright statement is from 2017 which does not mean that was the last 
date it was updated (which was in 2021 JFTR). 
Your eagerness to dismiss the official documentation, without any reason/base to 
do so ... I find that very odd.

> Anyway, does CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE still exist and, if so,
> is this configuration option off in Debian kernels?

Debian's kernel configuration is stored in /boot/config-$(uname -r) ...

> The original, user-level and high-level bug was that I noticed that I
> couldn't provably limit the processor speed via tlp after an upgrade
> from Debian 11 to Debian 12.  It took me quite a while (many hours
> spread over a few days) to get from that high level to the level of
> #1038981, and, as you surely understand, at a certain point I have to
> declare the boundary of my current expertise.

Please read https://xyproblem.info/

I'll have another reading suggestion in another reply ...

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: