@xnox, one can detect the machine type from the DMI data (iff it is available and reliable).
e.g. on my laptop: sudo dmidecode -s "chassis-type" Notebook on my desktop server: sudo dmidecode -s "chassis-type" There are quite a few chassis-type, see https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.1.pdf - page 36, section 7.4.1, table 16 "System Enclosure or Chassic Type". *Note* some machines may have illegal data or omitted this information and it's DMI specific, so s390, arm64, ppc64el platforms most probably won't have this. So some context. This performance governor was chosen for the boot default setting because it speeds up boot. I've performed some simple boot tests on an older generation Lenovo x220 (i3-2350M), timings are below for a 5.8 kernel: Governor Kernel Userspace EndBoot PEFORFMANCE 2.15s 10.37s 12.52s POWERSAVE 2.87s 18.49s 21.37s ONDEMAND 2.41s 10.46s 12.87s So PERFORMANCE saves a few tenths of a second over ONDEMAND, hence this choice for boot. The setting thereafter is obviously more complex. I've compared the governor settings on the same laptop running idle, with 50% CPU utilization and 100% CPU utilization. I used powerstat to monitor CPU power, CPU freq and C7 (deep sleep) residency. 1. Idle. - power utilization roughly the same in power usage, but powersave clocks the CPU lowest. Note that the CPU freq is cranked up when measurements are taken, so it's hard to get a correct freq. measurement. 2. 50% CPU busy. - performance consumes most power (as expected) and the CPU is running marginally faster than on-demand. 3. 100% CPU busy. - performance and on-demand are comparable in terms of power consumption and CPU frequency. PERFORMANCE essentially runs the CPU at higher frequency all the time, whereas ONDEMAND will scale up/down depending on the utilization. I believe the default should be ONDEMAND post boot as this is the most flexible option and will provide power saving when the system is less utilized. If users want to burn power and they can opt-in to manually setting to PERFORMANCE, but I think this should be opt-in rather than the default setting for any class of machine. Finally, if we don't want the userspace changes, we could default the kernel to ONDEMAND and take a hit on slower boot performance. To clarify I see the options as: 1. Boot with PERFORMANCE and fix the userspace to set ONDEMAND in the post-boot stage 2. Failing this, don't let userspace do anything smart post-boot and default to ONDEMAND Attached are some data points I gathered with the 5.8 kernel. ** Attachment added: "LibreOffice |Calc spread sheet of boot timings and power measurements" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+attachment/5402512/+files/2020-5.8-CPU-GOVERNOR-CONFIG.ods -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1885730 Title: Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in linux source package in Focal: New Status in systemd source package in Focal: Fix Released Status in linux source package in Groovy: Confirmed Status in systemd source package in Groovy: Invalid Bug description: In a recent merge from Debian we lost ondemand.service, meaning all CPUs now run in Turbo all the time when idle, which is clearly suboptimal. The discussion in bug 1806012 seems misleading, focusing on p-state vs other drivers, when in fact, the script actually set the default governor for the pstate driver on platforms that use pstate. Everything below only looks at systems that use pstate. pstate has two governors: performance and powerstate. performance runs CPU at maximum frequency constantly, and powersave can be configured using various energy profiles energy profiles: - performance - balanced performance - balanced power - power It defaults to balanced performance, I think, but I'm not sure. Whether performance governor is faster than powersave governor is not even clear. https://www.phoronix.com/scan.php?page=article&item=linux50-pstate- cpufreq&num=5 benchmarked them, but did not benchmark the individual energy profiles. For a desktop/laptop, the expected behavior is the powersave governor with balanced_performance on AC and balanced_power on battery. I don't know about servers or VMs, but the benchmark series seems to indicate it does not really matter much performance wise. I think most other distributions configure their kernels to use the powersave governor by default, whereas we configure it to use the performance governor and then switch it later in the boot to get the maximum performance during bootup. It's not clear to me that's actually useful. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
