revisit /etc/init.d/ondemand

[Martin Pitt]

We've been carrying /etc/init.d/ondemand for many years. We should revisit if booting with a kernel that defaults to "ondemand" right away is still actually slower than "performance".

In the short term, systemd should grow a "Type=idle" unit that switches to ondemand, to replace the static "1 minute" sleep. This will also get rid of the last init.d script in "initscripts" that we actually use, and pave the way for dropping the initscripts package.

In the long term, we could drop it completely if "ondemand" DTRT.

[Haw Loeung (hloeung)]

Bug #1579278 to consider switching to "performamce" may be of relevance here.

[Martin Pitt (pitti)]

Holding the porting to a systemd unit until we have some updated measurements and a decision whether we'll move to "performance" as default or keep the current logic.

[Colin Ian King (colin-king)]

Some data to take into consideration. I've tested 4 difference configs (3 laptops, 1 server) of mixed Intel and AMD hardware, comparing the default powersave/ondemand [1] vs performance

[1] depends on CPU and if intel-pstate is supported

For faster modern Intel CPUs where intel-pstate is supported, there is minimal difference. Otherwise, performance is a ~3% faster, and all the gains are in userspace.

See attached spreadsheet.

Tests data was gathered from the average of 25 and average of 50 boots per CPU scheduler setting. So that's a total of 600 boots in this dataset across a range of H/W, so I think this data is pretty reliable data.

[Martin Pitt (pitti)]

Thanks Colin! So this confirms that we really should let the kernel be in "performance" during boot. But from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579278/comments/9 it actually sounds like we should leave it to "performance" all the time at least for processors which are ≤ 5 years old, as changing to "ondemand" is actually detrimental to power saving. So for those we don't need the init script at all, but if there's a simple way to tell apart these cases, then the init script could just not do anything on those newer processors, so that we can slowly phase this out.

[Martin Pitt (pitti)]

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"?

[dino99 (9d9)]

Note that with old cpu (Piv q9550) the cpufreq subdir does not exist (with or without cpufreq* installed).
So checking that path will always fails.

 ls /sys/devices/system/cpu/cpu0/
cache driver microcode subsystem uevent
crash_notes firmware_node node0 thermal_throttle
crash_notes_size hotplug power topology

[Martin Pitt (pitti)]

Closing the kernel task, as it's now obvious that we want to keep the "performance" default there, and only do the "ondemand" thing for older processors.

[Martin Pitt (pitti)]

@dino99: That's fine, the script has

AVAILABLE="/sys/devices/system/cpu/cpu$FIRSTCPU/cpufreq/scaling_available_governors"
[ -f $AVAILABLE ] || exit 0

thus it's a no-op for those cases.

[Martin Pitt (pitti)]

http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=2558ca88

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 230-3git1

---------------
systemd (230-3git1) yakkety; urgency=medium

  Upload current Debian packaging git to fix tests.

  [ Martin Pitt ]
  * tmp.mount: Add nosuid and nodev mount options. This restores compatibility
    with the original SysV int RAMTMP defaults. (Closes: #826377)
  * debian/tests/upstream: Some tests fail on platforms without QEMU at the
    moment due to upstream PR#3587; blacklist these for now if QEMU is not
    available.
  * debian/rules: Don't run the "anything links against /usr" check for
    upstream tests, as those run on Ubuntu 16.04 LTS which does not yet have
    libidn moved to /lib.
  * debian/tests/upstream: Clean up old journals before running a test, to
    avoid printing a wrong one on failure.
  * debian/tests/upstream: Do not run the QEMU tests on i386. Nested QEMU on
    i386 causes testbed hangs on Ubuntu's cloud infrastructure, which is the
    only place where these actually run.

  [ Laurent Bigonville ]
  * Build with IDN support. (Closes: #814528)

 -- Martin Pitt <email address hidden> Thu, 23 Jun 2016 10:51:14 +0200