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

Groups > linux.debian.kernel > #79416 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  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

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

[Multipart message — attachments visible in raw view] — view raw

Package: linux-image-6.1.0-9-amd64
Version: 6.1.27-1
Below, I try to cap the frequency for each of my processor cores, but some cores resists:
# 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 400002 400004 399989 2300000 2300000 2300000 400013 399519
Moreover, the cores that resist changes each time; e.g., the next run yields this:
# 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 400024 2300000 400002 400020 2300000 400000 399930 400008
I tried to read the frequency via /proc/cpuinfo:
# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done && cat /proc/cpuinfo | grep MHz cpu MHz : 400.001 cpu MHz : 399.989 cpu MHz : 2300.000 cpu MHz : 400.107 cpu MHz : 1028.210 cpu MHz : 399.942 cpu MHz : 400.001 cpu MHz : 400.004
I also tried to use tlp (yes, I said TLP_DEFAULT_MODE=BAT, TLP_PERSISTENT_DEFAULT=1, CPU_BOOST_ON_BAT=0, and CPU_HWP_DYN_BOOST_ON_BAT=0) and sysfs packages; all methods yield the similar results: capping the frequency of all cores doesn't work. I tried to cap all at, say, 800 MHz, 1.2 GHz, and 2 GHz instead, but the result is often (but not always!) the same: a few cores often (but not always!) resist and run at higher frequencies up to 2.4 GHz. Only seldom I see the expected:
# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done && cat /proc/cpuinfo | grep MHz cpu MHz : 400.004 cpu MHz : 399.988 cpu MHz : 399.999 cpu MHz : 400.011 cpu MHz : 399.980 cpu MHz : 400.048 cpu MHz : 400.002 cpu MHz : 400.008
But running cat /proc/cpuinfo | grep MHz a few seconds later yields again a few lines with 2300.000.
The governor is powersave everywhere.
For kernel 5 with Debian 11 (which I can no longer test), everything worked like a charm (or at least I always observed all-400-MHz back then). So either the new kernel is erroneous or my processor broke somehow (perhaps, during the upgrade). It has Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz.
Who is the culprit? What to do?
Gratefully,
AlMa

[toc] | [next] | [standalone]

#79417 — Bug#1038981: Acknowledgement (capping maximum frequency no longer works in kernel 6.1)

I take back "often" and "seldom" because after having heavily loaded the 
laptop with computations, I observed around 400 MHz for all 8 cores 
twice.  Though I did observe what I wrote, I cannot claim "often" and 
"seldom" for the future behavior beyond reasonable doubt.

So instead of

“… often (but not always!) the same: a few cores often (but not always!) 
resist and run at higher frequencies up to 2.4 GHz. Only seldom …“

please read

“… sometimes similar: a few cores sometimes resist and run at higher 
frequencies up to 2.4 GHz. Sometimes …”

[toc] | [prev] | [next] | [standalone]

#79649 — Bug#1038981: scaling_cur_freq ≰ scaling_max_freq

[Multipart message — attachments visible in raw view] — view raw

found 1038981 linux-image-6.1.0-10-amd64/6.1.37-1
found 1038981 linux/6.1.0-10
thanks
The same problem exists after the recent kernel upgrade to linux-image-6.1.0-10-amd64 version 6.1.37-1.
$ uname -r
6.1.0-10-amd64
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
400000
400000
400000
400000
400000
400000
400000
400000
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
400016
399983
400012
400008
400015
399995
400016
2300000
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
400000
400000
400000
400000
400000
400000
400000
400000
As we see, the value 2300000 is too high! I'd expect around 400000. As the fun is running, the reported elevated values (here, 2.4 GHz) are probably real.
Gratefully,
AlMa

[toc] | [prev] | [next] | [standalone]

#79852

[Multipart message — attachments visible in raw view] — view raw

On Saturday, 24 June 2023 00:19:50 CEST Al Ma wrote:
> Below, I try to cap the frequency for each of my processor cores, but some
> cores resists: ...
> ...
> The governor is powersave everywhere.

If I put "powersave frequency governor" in a search engine, one of the first 
results points to arch wiki, so of course I check that first:
https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_governors
which says "powersave 	Run the CPU at the minimum frequency"
which indicates that you're trying to do the exact same thing as the governor 
already does. Why?!? (rhetorical question, don't answer it) ...

> For kernel 5 with Debian 11 (which I can no longer test), everything worked

Reverting back to Debian 11 userland is difficult (and likely irrelevant), but 
trying the 5.10 kernel should still be possible afaik.

> like a charm (or at least I always observed all-400-MHz back then). So
> either the new kernel is erroneous or my processor broke somehow (perhaps,
> during the upgrade). It has Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz. 

... That same wiki page has a purple box saying:
"Note: Each governor is compatible with any scaling driver, with the 
exceptions of intel_pstate and amd_pstate in active mode, which provide 
pseudo-governors in the form of powersave and performance. See #Autonomous 
frequency scaling below."

follow that link and you'll see
"Both Intel and AMD define a way to have the CPU decide its own speed"

You have an intel CPU, so I put "Intel p-state" in a search engine and one of 
the first results points to a document on kernel.org. Update version number to 
6.1: https://www.kernel.org/doc/html/v6.1/admin-guide/pm/intel_pstate.html

> Who is the culprit? What to do?

I literally put 2 questions in a search engine and the very first link I 
checked from each result (arch wiki + kernel.org) gave me the likely answer or 
enough information to do an actual deep dive.

I don't want to be an ass, but why didn't you do such elementary research 
before filing a bug report?

[toc] | [prev] | [next] | [standalone]

#79861

> I don't want to be an ass, but why didn't you do such elementary research
> before filing a bug report?

I don't want to be an ass, too, but the fact that you searched for 
exactly "powersave frequency governor" and “Intel p-state” (and NOT 
something else) is elementary to YOU.  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 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. (To compare, certain 
configuration files, such as /etc/lvm.conf or /etc/default/grub, get 
partially outdated with every upgrade of Debian stable.) Anyway, does 
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE still exist and, if so, is this 
configuration option off in Debian kernels?  That's what seems to be the 
case based on
https://www.google.com/search?q="CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE"+amd64+site%3Adebian.org 
, but I can't be sure …

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.

Gratefully,
AlMa

[toc] | [prev] | [next] | [standalone]

#79866

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#79885

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web