@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
I've added the OEM Solutions Group team for awareness. I'm not sure what
the final fix will be since servers' and desktops'/laptops' ideal
default seem to be different, but most likely the certification tests
should be adjusted if we don't end up restoring the previous behaviour
of the
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Focal)
Status: New => Fix Released
--
You received this bug notification because you are a
> In benchmarking we didn't observe much computational difference
between the too once the CPU is fully loaded. However, cranking up or
cranking down the load one will discover that the performance setting is
more responsive than powersave.
this is exactly the problem in production environments;
> I would suggest switching back to powersave/ondemand either with a new
service or the kernel config.
re: new service, the existing package cpufrequtils (and related package
cpufreqd) provides a configurable service to manage governor settings
(and other related settings). The old ondemand
Hello!
Regarding the comment #8, I didn't get the same positive experience on
my side. It was more closer to what is described in comment #9. See bug
1889479 for more details.
I would suggest switching back to powersave/ondemand either with a new
service or the kernel config. Having a dedicated
@colin-king @juliank
It feels to me that the oem flavour should default to
(powersave/ondemand), as it is more-or-less laptop kernel flavour.
I feel like generic kernel flavour should remain on performance.
I feel like we should have a unit, that for chassis=laptop turns on
@Colin: I agree with all of that.
Our kernel-side default is not powersave, but performance, across
generic and oem, at the very least:
$ grep CPU_FREQ_DEFAULT_GOV_.*=y /boot/config-5.*
/boot/config-5.4.0-26-generic:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
The choice was made from running analysis on a wide range of Intel
machines, old and new. We are trying to select the optimal choice for a
wide range of CPUs for a wide range of use cases. Generally speaking,
the intel-pstate governor has deeper understanding of the processor
features and can
passing intel_pstate=disable_hwp on the kernel commandline causes the
kernel to scale the Core i5-8250U down to 1.6 GHz in performance mode,
but that's still a bit off from the 900 MHz it scales down to in
powersave mode.
I believe Windows also does not run the CPUs in performance mode by
default
The performance governor is the right choice for servers, but it's not
the right choice on non-server platforms, it's also not the default
kernel setting, it was set because we have the ondemand.service in
userspace that can change it back to ondemand (or well we have the
service because of that
I have a freshly installed 20.10 system running on a 2012 MacBook Air
(MBA 5,2) and it is completely silent and cold when being idle:
rbalint@chaos:~$ sudo cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have
** Tags added: id-5efdfa465220b783b19272c2
--
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
@xnox @juliank IMO there is no real need for different boot time and
post-boot governor.
I think where we would like to save power or be less noisy the
(possibly) faster boot does not have huge impact on user satisfaction.
I agree that fans should not be on all the time in laptops/desktops.
If
** Also affects: linux (Ubuntu Groovy)
Importance: Undecided
Status: Confirmed
** Also affects: systemd (Ubuntu Groovy)
Importance: Undecided
Status: New
** Tags removed: rls-gg-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
@rbalint As said before the kernel messages and bugs are irrelevant and
wrong. They pretend like intel_pstate is different, when in fact it's
this script that is configuring it here. And yes, it needs OS config.
Nor do other distros not do this, but we do it differently. We set the
@balint
Kernel has no facility to startup in one mode, and later transition to
another.
I think maybe we should measure the difference between "performance,
then on demand" vs "balanced performance".
If the difference is not significant, maybe we can simply change the
kernel default to
The commit message removing ondemand.service has several bug references, too:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=65f46a7d14b335e5743350dbbc5b5ef1e72826f7
remove Ubuntu-specific ondemand.service
New processors handle scaling/throttling in internal firmware
Tagging rls-gg-incoming so it's reviewed, that has a performance impact
on desktop and ideally should have been discussed before landing rather
than afterfact
** Tags added: rls-gg-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Someone probably needs to look at non-pstate systems as I have no idea
about them.
--
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
21 matches
Mail list logo
