Bugzilla – Bug 1218529
[sle15sp6][Build 45.1] Sysctl changes on 15-sp6, '/proc/sys/kernel/sched_energy_aware' is null
Last modified: 2024-01-09 14:34:39 UTC
## Description sle15sp6 build 45.1 Kernel version: 6.4.0-150600.4-default. I can see no content in '/proc/sys/kernel/sched_energy_aware' file, and 'sysctl -a' command can't list 'sched_energy_aware' as well. IMO, the file content should be '1' or '0'. [it is '1' on sle15sp5] # cat /proc/sys/kernel/sched_energy_aware # sysctl -a | grep aware ----------------------------------------------------------------------- ## openQA Observation openQA test in scenario sle-15-SP6-Online-x86_64-sles-sys-param-check@64bit-2gbram fails in [Sysctl](https://openqa.suse.de/tests/13186107/modules/Sysctl/steps/136) ## Test suite description https://gitlab.suse.de/qa-css/sys-param-check ## Reproducible Fails since (at least) Build [45.1](https://openqa.suse.de/tests/13135907) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit-2gbram&test=sles-sys-param-check&version=15-SP6)
The latest SLE15-SP6 KOTD shows the file on my local boot. Could you verify it? The kernel is found in IBS Devel:Kernel:SLE15-SP6 or OBS Kernel:SLE15-SP6 repos.
(In reply to Takashi Iwai from comment #1) > The latest SLE15-SP6 KOTD shows the file on my local boot. > Could you verify it? The kernel is found in IBS Devel:Kernel:SLE15-SP6 or > OBS Kernel:SLE15-SP6 repos. I can reproduce the issue with the kernel: http://download.suse.de/ibs/Devel:/Kernel:/SLE15-SP6/standard/x86_64/kernel-default-6.4.0-150600.181.1.ge75469f.x86_64.rpm susetest:~ # uname -r 6.4.0-150600.181.ge75469f-default susetest:~ # ll /proc/sys/kernel/sched_energy_aware -rw-r--r-- 1 root root 0 Jan 7 20:55 /proc/sys/kernel/sched_energy_aware susetest:~ # cat /proc/sys/kernel/sched_energy_aware ------------------------------------------
I understood now that you're reporting about the empty output. This comes from the upstream change in commit 8f833c82cdab7b4049bcfe88311d35fa5f24e422 sched/topology: Change behaviour of the 'sched_energy_aware' sysctl, based on the platform The 'sched_energy_aware' sysctl is available for the admin to disable/enable energy aware scheduling(EAS). EAS is enabled only if few conditions are met by the platform. They are, asymmetric CPU capacity, no SMT, schedutil CPUfreq governor, frequency invariant load tracking etc. A platform may boot without EAS capability, but could gain such capability at runtime. For example, changing/registering the cpufreq governor to schedutil. At present, though platform doesn't support EAS, this sysctl returns 1 and it ends up calling build_perf_domains on write to 1 and NOP when writing to 0. That is confusing and un-necessary. Desired behavior would be to have this sysctl to enable/disable the EAS on supported platform. On non-supported platform write to the sysctl would return not supported error and read of the sysctl would return empty. So sched_energy_aware returns empty - EAS is not possible at this moment This will include EAS capable platforms which have at least one EAS condition false during startup, e.g. not using the schedutil cpufreq governor sched_energy_aware returns 0 - EAS is supported but disabled by admin. sched_energy_aware returns 1 - EAS is supported and enabled. User can find out the reason why EAS is not possible by checking info messages. sched_is_eas_possible returns true if the platform can do EAS at this moment. So this is intentional behavior.
(In reply to Takashi Iwai from comment #3) > I understood now that you're reporting about the empty output. > > This comes from the upstream change in commit > 8f833c82cdab7b4049bcfe88311d35fa5f24e422 > sched/topology: Change behaviour of the 'sched_energy_aware' sysctl, > based on the platform > > The 'sched_energy_aware' sysctl is available for the admin to > disable/enable > energy aware scheduling(EAS). EAS is enabled only if few conditions are > met by the platform. They are, asymmetric CPU capacity, no SMT, > schedutil CPUfreq governor, frequency invariant load tracking etc. > A platform may boot without EAS capability, but could gain such > capability at runtime. For example, changing/registering the cpufreq > governor to schedutil. > > At present, though platform doesn't support EAS, this sysctl returns 1 > and it ends up calling build_perf_domains on write to 1 and > NOP when writing to 0. That is confusing and un-necessary. > > Desired behavior would be to have this sysctl to enable/disable the EAS > on supported platform. On non-supported platform write to the sysctl > would return not supported error and read of the sysctl would return > empty. So sched_energy_aware returns empty - EAS is not possible at this > moment > This will include EAS capable platforms which have at least one EAS > condition false during startup, e.g. not using the schedutil cpufreq > governor > sched_energy_aware returns 0 - EAS is supported but disabled by admin. > sched_energy_aware returns 1 - EAS is supported and enabled. > > User can find out the reason why EAS is not possible by checking > info messages. sched_is_eas_possible returns true if the platform > can do EAS at this moment. > > So this is intentional behavior. Thanks much for your update! then I will change my test code to skip checking it.
Thanks, then I close as FEATURE.