Bug#1038981: capping maximum frequency no longer works in kernel 6.1
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.
Reply to: