In yakkety I'll add an ondemand.service to systemd, as
/etc/init.d/ondemand fell out of the standard installation (as
"initscripts" is now -- thankfully -- gone). I'll keep the xenial task
in case someone is interested in SRUing this.
** Changed in: sysvinit (Ubuntu)
Status: New => Invalid
So it seems we should make the "ondemand" init script a no-op if
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver contains
"intel_pstate", since in this case "ondemand" is worse than
"performance"?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
In that same Google+ post, Arjan van de Ven wrote:
"""
Now, about ondemand and cpufreq.
The ondemand algorithm was designed roughly 10 years ago, for CPUs from that
era. If you look at what ondemand really ends up doing, is managing the
frequency during idle periods, and 10 years ago, that matte
Bug #1188647 enables Intel PSTATE by default.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sysvinit in Ubuntu.
https://bugs.launchpad.net/bugs/1579278
Title:
Consider changing default CPU frequency scaling governor back
It looks like /etc/init.d/ondemand doesn't have any support for the
performance governor at all. On systems that only have "performance" and
"powersave" the only thing /etc/init.d/ondemand will do is set the
governor to powersave.
I'll file the appropriate bug against the initscripts package.
--
Ah thanks. So maybe /etc/init.d/ondemand should have something to
override or disable it (say DISABLE=1 in /etc/default/ondemand)?
Looking at it currently, it seems to prefer governors in this order -
interactive, ondemand, powersave. Even an option in
/etc/default/ondemand to specify the preferr
6 matches
Mail list logo
