Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
On 13/07/2022 17:12, killermoe...@gmx.net wrote:
This must explain why my modprobe.d (of acpi_cpufreq) seems to always work but
not why tmpfiles.d or a .service unit :
Actually, your modprobe.d is much too late
Well, maybe we don't talk about the same thing: I'm only interested in
/sys/devices/system/cpu/cpufreq/boost file.
I can echo 0 or 1 into this file anytime long after boot and verify
(running 'stress' for instance) in /proc/cpuinfo that core frequencies
are boosted or limited (lscpu does not seem to update the info though).
Besides, rmmod'ing the acpi_cpufreq module makes the 'boost' file vanish
(which seems normal according documentation)
The driver absolutely loaded, as stated earlier. What I find interesting is the
error message you get with
/sys/devices/system/cpu/cpufreq/boost: Permission denied
Agreed. Assuming module is loaded (hence file present) maybe there's a
critical section where it does not have the correct permission ? However
a standard systemd service (with default dependencies) comes quite late
in the boot process...
Did it failed because the file didn’t exists? Maybe the path you used is wrong?
I don't know. I initially thought about a race thinking that it was some
systemd services (udevd.service ?) that created or chmoded the file. But
(see above) this does not seem to be the case or is it ?
In this case I think your best bet is to disable the most option in the
BIOS/UEFI. At least
https://urldefense.com/v3/__https://docs.kernel.org/admin-guide/pm/cpufreq.html*rationale-for-boost-control-knob__;Iw!!JFdNOqOXpB6UZW0!t1eSenFnShc2J6NFFCaKdU-KiALOpOCGtva-oRXD7dih4zXs-yXPrA0wcas3OKKLGw4wKo646cvZDartCoacDVmvAi4$
is speaking of that.
If you don’t have such option in the BIOS/UEFI settings, you could try some
udev rule reacting to the /sys entry. Something like
`/etc/udev/rules.d/20-disable-cpu-boost.rules`
```
KERNEL=="cpu", ATTR{cpufreq/boost}=="1", ATTR{cpufreq/boost}:="0"
```
Thanks yes, I thought about it. Would like to understand what's failing
in my original naive setting (tmpfiles or service).
Thanks again anyway.
--
Thomas HUMMEL
Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
> This must explain why my modprobe.d (of acpi_cpufreq) seems to always work
> but not why tmpfiles.d or a .service unit :
Actually, your modprobe.d is much too late, if I understand correctly. The used
power manager module/options are set during the kernel start and can’t be
changed later. Only the governor used by the module could be changed, not the
module itself.
> As a matter of fact, I assume that since the /sys files seem to be created
> "at initialisation" or more precisely for the boost file, at driver, is
> exposed by the kernel module, this should be done long before
> systemd-tmpfiles-setup.service or my custom service are run ?
The actual structure _exposed_ via sysfs is created during kernel start and
module load. /sys only allows you simple access to it. With systemd, /sys is
considered an API filesystem, so it’s always mounted and available (AFAIK it’s
so early that’s done by PID1 itself before starting anything else). But on
systems without you don’t necessary have a /sys mount point. The structure
would still be in the kernel, though.
> The only reason I can think of for those 2 latter setup to fail is that
> driver has not been loaded yet, hence the
> /sys/devices/system/cpu/cpufreq/boost file not existing yet, but I find this
> weird.
The driver absolutely loaded, as stated earlier. What I find interesting is the
error message you get with
> /sys/devices/system/cpu/cpufreq/boost: Permission denied
Did it failed because the file didn’t exists? Maybe the path you used is wrong?
>> Question I have is: why do you want to disable boosting?
>
> One reason is because of rack density/input pdu power ratio.
> Another might be performance consistency (at least for benching)
In this case I think your best bet is to disable the most option in the
BIOS/UEFI. At least
https://docs.kernel.org/admin-guide/pm/cpufreq.html#rationale-for-boost-control-knob
is speaking of that.
If you don’t have such option in the BIOS/UEFI settings, you could try some
udev rule reacting to the /sys entry. Something like
`/etc/udev/rules.d/20-disable-cpu-boost.rules`
```
KERNEL=="cpu", ATTR{cpufreq/boost}=="1", ATTR{cpufreq/boost}:="0"
```
Totally untested, btw.
BR
Silvio
Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
On 13/07/2022 00:35, Silvio Knizek wrote: Am Dienstag, dem 12.07.2022 um 18:55 +0200 schrieb Thomas HUMMEL: Hi, Hello, thanks for your answer first of all, no need for /sys in /etc/fstab. /sys will _always_ be mounted by systemd. Ok. This must be put by our image generating tool. Second, this sounds really depending on your used driver (acpi, amd, or intel). Check out the documentation at https://docs.kernel.org/admin-guide/pm/cpufreq.html Well, this states: "During the initialization of the kernel, the CPUFreq core creates a sysfs directory (kobject) called cpufreq under /sys/devices/system/cpu/." This must explain why my modprobe.d (of acpi_cpufreq) seems to always work but not why tmpfiles.d or a .service unit : As a matter of fact, I assume that since the /sys files seem to be created "at initialisation" or more precisely for the boost file, at driver, is exposed by the kernel module, this should be done long before systemd-tmpfiles-setup.service or my custom service are run ? The only reason I can think of for those 2 latter setup to fail is that driver has not been loaded yet, hence the /sys/devices/system/cpu/cpufreq/boost file not existing yet, but I find this weird. Question I have is: why do you want to disable boosting? One reason is because of rack density/input pdu power ratio. Another might be performance consistency (at least for benching) Thanks for your help -- Thomas HUMMEL
Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
Am 13.07.22 um 00:11 schrieb Leon Fauster: Am 12.07.22 um 18:55 schrieb Thomas HUMMEL: Hello, I'm using systemd-239-45 on RHEL 8.4 x86_64 AMD nodes on which I disable Turbo Core/Turbo Boost by writing '0' into the following file: Uups, the AMD string was not recognized. So, my comments are only for intel cpus. /sys/devices/system/cpu/cpufreq/boost What about /sys/devices/system/cpu/intel_pstate/no_turbo ? And check your actual config profile. Some "major" settings must be set adequately to allow having a specific config. cat /sys/devices/system/cpu/cpufreq/*/energy_performance_preference cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor https://www.kernel.org/doc/html/v4.13/admin-guide/pm/intel_pstate.html 2) adding an entry for systemd-tmpfiles-setup.service like this: w /sys/devices/system/cpu/cpufreq/boost - - - - 0 Using the same approach with success here for the scaling_governor. a) SELinux is disabled Sorry that I have to say, in 2022 disabling SELinux is like having Win95 installed ... and more important, in the future you will not be able to disable it. So, better get in touch with it. -- L
Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
Am Dienstag, dem 12.07.2022 um 18:55 +0200 schrieb Thomas HUMMEL: > Hello, > > I'm using systemd-239-45 on RHEL 8.4 x86_64 AMD nodes on which I disable > Turbo Core/Turbo Boost by writing '0' into the following file: > > /sys/devices/system/cpu/cpufreq/boost > > I want it to be disabled automatically at boot. For that matter I tried > 3 different ways (only one at a time) > > 1) a service unit configured like this: > > [Unit] > Description=Disable CPU Turbo Boost > > > [Service] > # using tee here to have an output in journalctl to understand when this > service > # fails to start > ExecStart=/bin/sh -c "/usr/bin/echo 0 | /bin/tee > /sys/devices/system/cpu/cpufreq/boost" > ExecStop=/bin/sh -c "/usr/bin/echo 1 | /bin/tee > /sys/devices/system/cpu/cpufreq/boost" > RemainAfterExit=yes > > [Install] > WantedBy=sysinit.target > > 2) adding an entry for systemd-tmpfiles-setup.service like this: > > w /sys/devices/system/cpu/cpufreq/boost - - - - 0 > > 3) using modprobe.d like this: > > install acpi_cpufreq /sbin/modprobe --ignore-install acpi_cpufreq > $CMDLINE_OPTS && echo 0 > /sys/devices/system/cpu/cpufreq/boost > > > I noticed that *sometimes* using 1) or 2) > /sys/devices/system/cpu/cpufreq/boost ended up with '1' instead of '0' > > I didn't see any error in journal for 2) (tmpfiles.d option) and for 1) > (systemd service) I saw: > > > Jul 04 15:06:25 systemd[1]: Started Disable CPU Turbo Boost. > Jul 04 15:06:25 sh[2788]: /bin/tee: > /sys/devices/system/cpu/cpufreq/boost: Permission denied > Jul 04 15:06:25 sh[2788]: 0 > Jul 04 15:06:25 systemd[1]: disable-cpu-turboboost.service: Main > process exited, code=exited, status=1/FAILURE > Jul 04 15:06:25 systemd[1]: disable-cpu-turboboost.service: Failed > with result 'exit-code'. > > I did not manage to find out if there were a race condition and if so > what ordering dependencies should be stated. > I tried to compare a "working" and "not working" systemd-analyse output > but I did not find anything obvious (at least for me) > > Besides, /sys is mounted in the fstab (as expected) > > sysfs /sys sysfsdefaults 0 0 > > is there a corresponding transient .mount unit somewhere ? > > Notes: > > a) SELinux is disabled > > b) I don't think any other service or process is touching the > /sys/devices/system/cpu/cpufreq/boost file > > c) in the event the system boot up with the wrong value, manually echo 0 > into the file (which exists) always work > > Can you help me figuring in what direction I should look, if it is > systemd related at all ? > > Thanks for your help > > -- > Thomas HUMMEL Hi, first of all, no need for /sys in /etc/fstab. /sys will _always_ be mounted by systemd. Second, this sounds really depending on your used driver (acpi, amd, or intel). Check out the documentation at https://docs.kernel.org/admin-guide/pm/cpufreq.html and always check the Arch wiki https://wiki.archlinux.org/title/CPU_frequency_scaling as well. Question I have is: why do you want to disable boosting? BR Silvio signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
Am 12.07.22 um 18:55 schrieb Thomas HUMMEL: Hello, I'm using systemd-239-45 on RHEL 8.4 x86_64 AMD nodes on which I disable Turbo Core/Turbo Boost by writing '0' into the following file: /sys/devices/system/cpu/cpufreq/boost What about /sys/devices/system/cpu/intel_pstate/no_turbo ? And check your actual config profile. Some "major" settings must be set adequately to allow having a specific config. cat /sys/devices/system/cpu/cpufreq/*/energy_performance_preference cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor https://www.kernel.org/doc/html/v4.13/admin-guide/pm/intel_pstate.html 2) adding an entry for systemd-tmpfiles-setup.service like this: w /sys/devices/system/cpu/cpufreq/boost - - - - 0 Using the same approach with success here for the scaling_governor. a) SELinux is disabled Sorry that I have to say, in 2022 disabling SELinux is like having Win95 installed ... and more important, in the future you will not be able to disable it. So, better get in touch with it. -- L
[systemd-devel] Disabling cpufreq/boost at boot time sometimes fails
Hello, I'm using systemd-239-45 on RHEL 8.4 x86_64 AMD nodes on which I disable Turbo Core/Turbo Boost by writing '0' into the following file: /sys/devices/system/cpu/cpufreq/boost I want it to be disabled automatically at boot. For that matter I tried 3 different ways (only one at a time) 1) a service unit configured like this: [Unit] Description=Disable CPU Turbo Boost [Service] # using tee here to have an output in journalctl to understand when this service # fails to start ExecStart=/bin/sh -c "/usr/bin/echo 0 | /bin/tee /sys/devices/system/cpu/cpufreq/boost" ExecStop=/bin/sh -c "/usr/bin/echo 1 | /bin/tee /sys/devices/system/cpu/cpufreq/boost" RemainAfterExit=yes [Install] WantedBy=sysinit.target 2) adding an entry for systemd-tmpfiles-setup.service like this: w /sys/devices/system/cpu/cpufreq/boost - - - - 0 3) using modprobe.d like this: install acpi_cpufreq /sbin/modprobe --ignore-install acpi_cpufreq $CMDLINE_OPTS && echo 0 > /sys/devices/system/cpu/cpufreq/boost I noticed that *sometimes* using 1) or 2) /sys/devices/system/cpu/cpufreq/boost ended up with '1' instead of '0' I didn't see any error in journal for 2) (tmpfiles.d option) and for 1) (systemd service) I saw: Jul 04 15:06:25 systemd[1]: Started Disable CPU Turbo Boost. Jul 04 15:06:25 sh[2788]: /bin/tee: /sys/devices/system/cpu/cpufreq/boost: Permission denied Jul 04 15:06:25 sh[2788]: 0 Jul 04 15:06:25 systemd[1]: disable-cpu-turboboost.service: Main process exited, code=exited, status=1/FAILURE Jul 04 15:06:25 systemd[1]: disable-cpu-turboboost.service: Failed with result 'exit-code'. I did not manage to find out if there were a race condition and if so what ordering dependencies should be stated. I tried to compare a "working" and "not working" systemd-analyse output but I did not find anything obvious (at least for me) Besides, /sys is mounted in the fstab (as expected) sysfs /sys sysfsdefaults 0 0 is there a corresponding transient .mount unit somewhere ? Notes: a) SELinux is disabled b) I don't think any other service or process is touching the /sys/devices/system/cpu/cpufreq/boost file c) in the event the system boot up with the wrong value, manually echo 0 into the file (which exists) always work Can you help me figuring in what direction I should look, if it is systemd related at all ? Thanks for your help -- Thomas HUMMEL
