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

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

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

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

Contents

  Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Diederik de Haas <didi.debian@cknow.org> - 2021-08-05 19:40 +0200
    Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2021-08-06 15:40 +0200
      Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Diederik de Haas <didi.debian@cknow.org> - 2021-08-06 16:10 +0200
        Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Diederik de Haas <didi.debian@cknow.org> - 2021-08-07 22:40 +0200
        Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Diederik de Haas <didi.debian@cknow.org> - 2021-09-27 03:10 +0200
    Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1 Diederik de Haas <didi.debian@cknow.org> - 2021-08-08 17:10 +0200
    Bug#991921: marked as done (linux: Please enable CPUFREQ options  for RPi 0/0w/1) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-11-04 10:10 +0100

#72563 — Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

Source: linux
Version: 5.10.46-3
Severity: wishlist
Tags: patch

At
https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
it was reported that CPU frequency scaling was enabled for armhf and
arm64, but not for armel. I (and others) have been able to confirm that.

So I build my own kernel with the following patch:
+CONFIG_CLK_RASPBERRYPI=y
+CONFIG_CPUFREQ_DT=m
+CONFIG_CPUFREQ_DT_PLATDEV=y
+CONFIG_ARM_RASPBERRYPI_CPUFREQ=m

-CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
+# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
-# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
-CONFIG_CPU_FREQ_GOV_ONDEMAND=m
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y

I 'heard' that the schedutil governor is good for big.little CPUs, but
the RPi 0/0w/1 is only (very) little ;-) so I chose 'ondemand' as
default governor. Feel free to change that.

After booting in that new kernel, `cpupower frequency-info` and `cat
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_*_freq` returned proper
results. On the RPi 1 it was only information as it only has 1
frequency: 700Mhz.
But Gunnar Wolf 'gwolf' downloaded my .deb files and installed it on his
0w and then he was able to switch between 700 and 1000Mhz.
https://nube.iiec.unam.mx/s/p4QLFp9i8baCYrt is a picture of it; don't
know how long that'll be available though.

So hereby the request to enable it in the config for the RPi 0/0w/1.

Cheers,
  Diederik

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: armel (armv6l)

Kernel: Linux 5.10.0-8-rpi
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#72568

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

Hello,

On Thu, Aug 05, 2021 at 05:26:09PM +0000, Diederik de Haas wrote:
> At
> https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> it was reported that CPU frequency scaling was enabled for armhf and
> arm64, but not for armel. I (and others) have been able to confirm that.
> 
> So I build my own kernel with the following patch:
> +CONFIG_CLK_RASPBERRYPI=y

Would CONFIG_CLK_RASPBERRYPI=m be enough?

> +CONFIG_CPUFREQ_DT=m
> +CONFIG_CPUFREQ_DT_PLATDEV=y
> +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m

These look reasonable.

> -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y

Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
able to switch to that if you prefer it?!

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

#72569

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

Hi,

On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 05:26:09PM +0000, Diederik de Haas wrote:
> > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> > 
> > So I build my own kernel with the following patch:
> > +CONFIG_CLK_RASPBERRYPI=y
> 
> Would CONFIG_CLK_RASPBERRYPI=m be enough?

Maybe. I haven't tried that. I 'copied' what was done for arm64 and armhf in
https://salsa.debian.org/kernel-team/linux/-/commit/7dc3d9453272836a9571c30b9776a85a5e41c657
https://salsa.debian.org/kernel-team/linux/-/commit/c4ab143979cc30c395251a48ba6b5b8969973b70

If I grep on CLK on configs on my amd64 machine and various RPi's, 
then they all have '=y' on them, so it appears to be the standard/norm.

> > +CONFIG_CPUFREQ_DT=m
> > +CONFIG_CPUFREQ_DT_PLATDEV=y
> > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m
> 
> These look reasonable.
> 
> > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> 
> Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> able to switch to that if you prefer it?!

Yes, afaik it isn't needed.
I did notice that there are 2 schedulers which are often used as default,
namely 'performance' and 'schedutil' and those are also builtin.
That's the reason I made 'ondemand' builtin as well, but it's entirely 
possible that correlation != causation and I inferred 
an incorrect 'conclusion'.

Trying to find why 'performance' and 'schedutil' were builtin, resulted in
https://salsa.debian.org/kernel-team/linux/-/commit/e5b976c268e44d452bc5ae23b765eab26c4409ae
which suggest the (sole) reason that it got builtin is that it couldn't be
modular in 4.9. That can very well have changed since.
It could be that 'performance' and 'schedutil' can now also be done as
modules, but that's outside the scope of this bug report.
And I don't think I'm qualified to make an informed choice/change on this.

Cheers,
  Diederik

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

#72577

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

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote:
> > > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > 
> > Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> > able to switch to that if you prefer it?!
> 
> Yes, afaik it isn't needed.
> I did notice that there are 2 schedulers which are often used as default,
> namely 'performance' and 'schedutil' and those are also builtin.
> That's the reason I made 'ondemand' builtin as well, but it's entirely
> possible that correlation != causation and I inferred
> an incorrect 'conclusion'.
> 
> Trying to find why 'performance' and 'schedutil' were builtin, resulted in
> https://salsa.debian.org/kernel-team/linux/-/commit/e5b976c268e44d452bc5ae23
> b765eab26c4409ae which suggest the (sole) reason that it got builtin is that
> it couldn't be modular in 4.9. That can very well have changed since.

If you do 'make menuconfig' and change the default governor, it automatically 
makes the matching CPU_FREQ_GOV_* parameter builtin. And you can't change 
that. And apparently you can't make CPU_FREQ_GOV_PERFORMANCE a module. At all.
So menuconfig is telling me that the default governor must use a builtin 
module.

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

#73080

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

Hi,

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote:
> On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote:
> > On Thu, Aug 05, 2021 at 05:26:09PM +0000, Diederik de Haas wrote:
> > > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> > > 
> > > So I build my own kernel with the following patch:
> > > +CONFIG_CLK_RASPBERRYPI=y
> > 
> > Would CONFIG_CLK_RASPBERRYPI=m be enough?
> 
> Maybe. I haven't tried that. I 'copied' what was done for arm64 and armhf in
> https://salsa.debian.org/kernel-team/linux/-/commit/7dc3d9453272836a9571c30
> b9776a85a5e41c657
> https://salsa.debian.org/kernel-team/linux/-/commit/c4ab143979cc30c395251a4
> 8ba6b5b8969973b70
> 
> If I grep on CLK on configs on my amd64 machine and various RPi's,
> then they all have '=y' on them, so it appears to be the standard/norm.

I just found out that on my Rock64 arm64 kernel the value is '=y'
$ grep CONFIG_CLK_RASPBERRYPI /boot/config-5.14.0-trunk-arm64 
CONFIG_CLK_RASPBERRYPI=y

And on top of that, this kernel config change is targeted at 
debian/config/armel/config.rpi which is a config file solely for the RPi 0/0w/1.
I understand/agree with the principle to enable things as modules as much as 
possible, but I don't think it's important in this specific case.
 
> > > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > 
> > Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> > able to switch to that if you prefer it?!

True, but I think 'performance' is a bad default scheduler in general as 
AFAICT it runs the CPU at full speed all the time.
In the case or RPi's I think it's especially bad as due to their low power 
consumption they're often on 24/7, while being idle most of the time.
With 'ondemand' it runs at lowest speed normally, but only scales up when 
needed, which I think is what most people want and expect.
So changing the default to 'ondemand' seems the right choice and the default 
governor must be builtin.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/381 is my MR to fix 
this bug and enable these changes in config.rpi.
(I'll soon update that MR and retarget it to master)

In that MR I've also made 'conservative' governor builtin.
While strictly not needed, this change is also restricted to config.rpi and 
it's the best governor for solar/battery powered devices, which is (afaik) a 
common use case for RPi 0/0w/1.
I'm _assuming_ that many users of RPi's are not tech-savvy and don't know that 
you can 'modprobe' additional governors if you want to use them.
In fact I only learned that recently. Previously I thought I couldn't use them 
because they didn't show up in the *available* governors. When a governor is 
loaded (or builtin), it does show up as an available governor.

Cheers,
   Diederik

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

#72581

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

On donderdag 5 augustus 2021 19:26:09 CEST Diederik de Haas wrote:
> I 'heard' that the schedutil governor is good for big.little CPUs, but

On my amd64 machine (with Ryzen 1800X CPU) 'schedutil' is enabled and set as 
default, so the above statement is a bit too simplistic.

> the RPi 0/0w/1 is only (very) little ;-) so I chose 'ondemand' as
> default governor. Feel free to change that.

What is relevant in this context is that CONFIG_CPU_FREQ_GOV_SCHEDUTIL depends 
on CONFIG_SMP, which is not set on config-5.10.0-8-rpi and it's probably not a 
good idea to change that as the RPi 0, 0w and 1 are all single core.
So 'ondemand' seems to be the proper choice, just for different reasons.

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

#73601 — Bug#991921: marked as done (linux: Please enable CPUFREQ options for RPi 0/0w/1)

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

Your message dated Thu, 04 Nov 2021 09:00:08 +0000
with message-id <E1miYbQ-000Hht-He@fasolo.debian.org>
and subject line Bug#991921: fixed in linux 5.15-1~exp1
has caused the Debian Bug report #991921,
regarding linux: Please enable CPUFREQ options for RPi 0/0w/1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
991921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991921
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

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

csiph-web