pm-utils: readahead and journal-commit waste power

Since the posting was on a private list, I'm putting a link into the results and spreadsheet data that covers the analysis:

Results: http://zinc.canonical.com/~cking/power-benchmarking/pm-utils-results/results.txt
Data: http://zinc.canonical.com/~cking/power-benchmarking/pm-utils-results/pm-tests.ods

== Journal-commit ==

script: power.d/journal-commit

For ext3/ext4 file systems this sets the journal commit time to 600
seconds(!) when on battery power.

Test: build busybox
Results: NO power savings on HDD drives, with biggest loss of 1.5% on
  SSD based netbook.

Recommendation: We remove this script for two reasons:
 1) It is shown not to save power on a busy system
 2) It is a dangerous option - pushing the commit timeout to 10 minutes
    increases the likely of filesystem errors on a system hang.

== Readahead ===

script: power.d/readahead

This script tries to trade off the number of times we spin up a drive to
read for potentially wasted cache. For AC power, set to 256KB, for battery
power, set to 3072KB.

Test: build busybox
Results: All systems fail to show any power savings, in fact SSD loses
  ~1.7% more power with this enabled.
Recommendation: Remove this script

Please refer to the pm-tests.ods for the results from some thorough testing on 3 representative machines.

Hi Colin,

Thanks for your work on profiling our power management!

> script: power.d/journal-commit

> Recommendation: We remove this script for two reasons:
> 1) It is shown not to save power on a busy system

Ok, but what about on an *idle* system? The premise is that during normal usage (and I don't consider running a package build normal usage), a system on battery should not need to wake up the disk at all more than once every few minutes. I know that on the desktop we appear to have other bugs causing this to not be the case, but I think that does need to remain the goal. If we're not thrashing the disk by doing a package build, does a higher journal commit time help or hinder power savings?

Hi Steve, I will re-rerun journal-commit on an idle system tomorrow and get back to you. Any ideas of scenarios that are typical and may generate typical I/O patterns?

As for the 600 second setting, it is a little scary to see it set so high and cause potential data loss risk. But, that's kinda incidental.

On Tue, Dec 06, 2011 at 09:39:48PM -0000, Colin King wrote:
> Hi Steve, I will re-rerun journal-commit on an idle system tomorrow and
> get back to you. Any ideas of scenarios that are typical and may
> generate typical I/O patterns?

I'd guess that typical patterns would include playing music via the default
music player, viewing static web pages, and viewing flash videos in a web
browser. (Other common scenarios when on battery might be composing email /
docs, but I guess those are harder to script for testing?)

> As for the 600 second setting, it is a little scary to see it set so
> high and cause potential data loss risk. But, that's kinda incidental.

Provided that we're using data=ordered (we are, aren't we? :-), I don't find
the prospect of 10 minutes of data loss while on battery terrifying,
especially provided there are syncs happening at sensible times (e.g.,
before suspending/hibernating?). And if it buys more battery life, the odds
of an unplanned power event go down, which seems like a win for data
integrity anyway.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve, I've re-instrumented the journal-commit tests this time using the following test methodology:

Start banshee playing some classical music (mp3)
Sleep 60 seconds
Start firefox, open tab on a blog containing flash adverts
Sleep 60 seconds
Open 2nd tab on firefox on a blog with lots of images, flash videos and adverts
Sleep 60 seconds
Open 3rd tab on firefox on slashdot.com
Sleep 60
Open 4th tab on firefox on boingboing.com
Sleep 60
Start thunderbird on an IMAP gmail mailbox (note, the folders
were pre-sync'd before running the test)
Sleep 60
kill banshee
Sleep 60
kill firefox
Sleep 60
Kill thunderbird
Sleep 20

This was run 5 x for two scenarios: journal-commit not enabled and journal commit enabled. I calculated the average and standard deviation. I ran this test methodology on two machines, a 64 bit Lenovo ThinkPad x220i (HDD) and a 32 bit HP mini 100 (SSD).

Attached is a LibreOffice spreadsheet of the data.

In both sets of tests there is no positive power saving, in fact the differences are within the the error margin of the measurements, so I can't see any positive benefit.

I could re-run these tests over night on the x220i with different values for the journal commit time if you want more data, but I really suspect we won't anything much different.

Sorry, forgot the spreadsheet data

@Steve, also attached are the results from pm-utils readahead tests run with the same testing scenarios as in #5

I suspect that readahead is marginally beneficial for systems with spinning media (within the margins of measurement error), and with SSDs (like my HP mini 10) it is definitely less power efficient. So my recommendation is to drop this, but it's a marginal case so it's not a big win or lose if we keep the status quo.

Unfortunately these tests take ~2+ hours to run per machine, and so further testing to tease this out is probably not beneficial in terms of time unless I can schedule in some automated soak tests over the weekends.

thanks, this looks pretty decisive that we're better off dropping these settings.

Forwarded upstream, and I asked Michael Biebl about this. He's both an upstream committer and the Debian maintainer, so we can sort this out in the Debian git. If he wants to keep them, I can do a commit to not install the scripts in an Ubuntu build.

Committed to Debian packaging git.

This bug was fixed in the package pm-utils - 1.4.1-8+git1

---------------
pm-utils (1.4.1-8+git1) precise; urgency=low

  Upload current Debian packaging GIT head (patches still need to be discussed
  with Debian/upstream before doing a Debian upload).

  * Add 26-inhibit-on-right-status.patch: Do not use the exit status of log
    rather the exit status of the hook thereby allowing inhibit to work.
    Thanks to Ariel Cornejo for the patch! (LP: #665651)
  * Add 01_xfs_buffer_arguments.patch: pm/power.d/xfs_buffer: Fix wrong
    argument ordering. Thanks to Andre Draszik for the patch!
    (LP: #645974)
  * debian/rules: Remove the journal-commit and readahead scripts. Recent
    measurements have shown that they do not save any power in different
    workloads on rotary disks, and in fact increase power usage on SSD.
    (fd.o #44627, LP: #900923)
  * Add debian/power.d/{pci_devices,usb_bluetooth}: Set USB bluetooth to
    autosuspend and a safe subclass of PCI devices to low-power mode during
    powersafe mode. (fd.o #44672, LP: #911325)
 -- Martin Pitt <email address hidden> Wed, 11 Jan 2012 15:26:02 +0100