Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #79885

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

Cross-posted to 2 groups.

Show all headers | View raw

> 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 ...

You seem to have domain knowledge without even realizing this.  The 
report has many phrases; you decided to choose this one particular. 
E.g., you could have chosen "/sys" and descend into the internals of how 
this directory works.

>> 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 ...
The wiki (again of a different distribution) has thousands of words and 
concepts.
> 
>> 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.
Having a way and using it is not the same.  Moreover, have the courtesy 
to read the context:  “4 Autonomous frequency scaling   Both Intel and 
AMD define a way to have the CPU decide its own speed based on (1) a 
performance range from the system and (2) a performance/power hint 
specifying the preference. The fully-autonomous mode is activated when: 
[…]”  Now you as the reader wonder about how on earth 8 simple `cat` 
commands could ask for performance, about the hint (and I did try to 
understand what power hints are though I've not mentioned this), and 
about the difference between just autonomous and _fully_ autonomous. 
However, the Website never mentions “fully” again, so as the reader you 
are being confused here again in addition to the confusion before.

> 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.

What you said is just weird. Debian and Arch use different versions 6.1 
and 6.4 (at least there's no good reason for them to sync up). Different 
version of a source are, strictly speaking, different.  I hope Debian 
doesn't require the admins to look into differences based on a Web 
search leading to some Web site of some other distribution.  And if the 
admins blindly base their decision on information from sources 
concerning other operating systems (to which you or a Web search pointed 
to) and anything breaks because of some small discrepancy, who would pay 
for their extra time (or hardware)?  Would you?

As for simple search, you probably think that I would've allegedly not 
done mine. I have. Quite a lot.  Still, at a certain point, it's the end 
of my expertise.

>> 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...
And today we have 2023, and the microarchitecture of the processor in 
question is not Sandy Bridge but Skylake. The phrase "and newer" usually 
refers to immediate successors (as for further successors, the chance of 
abandoning certain functionalities is higher). Anyway, the Web page you 
quote is about Arch.  Apriori, the information there may be partially 
(or completely) false for Debian, so everything written there should, by 
default, be taken with at least a grain of salt.

> 
> 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).
In the whole HTML document there is no single later date than 2017.

> Your eagerness to dismiss the official documentation, without any reason/base to
> do so ... I find that very odd.
Your eagerness to insult me just because Debian fails to have its own 
source of documentation on this matter is just odd.  Calm down.

> 
>> 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) ...

Finally a single bit use of useful answer.  Thanks for this, and I mean 
it.  You could have also said directly that the option is not set by 
default in linux-image-6.1.0-10-amd64.

 > Please readhttps://xyproblem.info/
 >
 > I'll have another reading suggestion in another reply ...

If instead of being thus sarcastic against me you file a 
bug/issue/suggestion report against tlp or sysfsutils or their 
documentation (e.g., to mention that users shouldn't expect the 
frequency to be absolutely capped or saying how to cap it), it could 
help the community a little bit more.

After all, from a viewpoint of a user of computing power, the whole 
automatic frequency up-scaling is pointless in our use case.  You as a 
user simply run `for i in `seq 0 7`; do echo "400000"> 
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq && cat 
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_cur_freq; done` on the 
command line and do nothing else.  For this task of executing `seq` and 
looping and thereby writing and printing short files _alone_ (and doing 
nothing else), you shouldn't need more processing power than that of an 
Intel 8088 clocked at 5 MHz, and, by default, your operating system 
shouldn't use more computing resources than your main task.  If it does 
so anyway, it's probably safe to say the operating system is 
inefficiently programmed or does something useless in addition.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#1038981: capping maximum frequency no longer works in kernel 6.1 "Al Ma" <alma0@ro.ru> - 2023-06-24 00:30 +0200
  Bug#1038981: Acknowledgement (capping maximum frequency no longer works in kernel 6.1) AlMa <AlMa0@ro.ru> - 2023-06-24 01:00 +0200
  Bug#1038981: scaling_cur_freq ≰ scaling_max_freq "Al Ma" <alma0@ro.ru> - 2023-07-20 01:30 +0200
  Bug#1038981: capping maximum frequency no longer works in kernel 6.1 Diederik de Haas <didi.debian@cknow.org> - 2023-08-01 00:20 +0200
    Bug#1038981: capping maximum frequency no longer works in kernel 6.1 AlMa <AlMa0@ro.ru> - 2023-08-01 01:50 +0200
      Bug#1038981: capping maximum frequency no longer works in kernel 6.1 Diederik de Haas <didi.debian@cknow.org> - 2023-08-01 10:50 +0200
        Bug#1038981: capping maximum frequency no longer works in kernel 6.1 AlMa <AlMa0@ro.ru> - 2023-08-01 16:50 +0200

csiph-web