[Pm-utils] Cutting down on unnecessary hooks

[Victor Lowther]

On Wed, 2008-11-26 at 11:31 -0800, Dan Nicholson wrote:
> Recently I was debugging some suspend issue and was using bare `echo
> mem > /sys/power/state'. Turns out, it was much faster than using
> pm-suspend. That got me thinking that the pm-utils hooks must be
> taking a long time. Looking at the current default hooks, it seems
> that some are useless or less than optimal.

I use this tiny little patch for profiling:


diff --git a/pm/pm-functions.in b/pm/pm-functions.in
index f5cc400..80797ee 100644
--- a/pm/pm-functions.in
+++ b/pm/pm-functions.in
@@ -92,7 +92,7 @@ log()
        [ $LOGGING ] || return 0;
        local fmt='%s\n'
        [ "$1" = "-n" ] && { fmt='%s'; shift; }
-       printf "$fmt" "$*"
+       printf "%s: $fmt" "$(date "+%F %T.%N")" "$*"
 }
 
 add_before_hooks() {

It is useful in identifying which hook takes so long.

> 49bluetooth: Disables/reenables IBM bluetooth.
> Shouldn't the kernel handle this if it's necessary? If it does, can we
> bail out if the kernel is new enough?

Mabye -- if you have hardware that we can test that hypothesis on, that
would be awesome.

> 50ntpd: Stops/starts ntpd.
> This seems completely wrong. First, ntpd surely knows how to handle
> the network going away suddenly. Suspend is not the only time when the
> network connection could be lost. Second, if it is deemed that
> stopping ntpd when the network goes away is necessary, wouldn't this
> be better handled by a NetworkManager dispatcher script? NM actually
> knows when the network is available, which is much better then the
> total hack here to sleep 20 seconds in the background in the hopes
> that the network will be available later.

No argument here.  If people want to drop this hook, fine with me.

> 55battery: Make HAL rescan the batteries on resume.
> Shouldn't gnome-power-manager (or whatever HAL using policy agent) be
> the one to tell HAL to do this? And since we're not doing anything
> with the reply, why do we need to specify a timeout?

Well, since according to Danny it already does, have no problems
dropping it when HAL will handle things properly.

As far as timeouts go, they are not as big a deal in the resume path --
by the time we get as far as this hook, we have already switched back to
the active console and the user has control.

> 65alsa: Store/restore the driver state.
> The comment here even says that newer ALSA doesn't need this. Can we
> bail out on newer kernels? Or drop it completely since these bugs
> should be fixed if they exist?

Hmmm... how far do we want to go to maintain backwards compatibility?

> 
> 90clock: Syncs to/from the hardware clock.
> Is this necessary? I honestly don't know.

It doesn't seem necessary on my system at all -- the only reason I ahve
not proposed dropping it is backwards compatibility.

> 94cpufreq: Sets the cpufreq governor to performance for suspending if available.
> I don't know why this would need to be done at all. If there are bugs
> suspending under certain governors, those bugs should be fixed. At the
> very least, I think TEMPORARY_CPUFREQ_GOVERNOR should be unset by
> default and the hook should bail out in that case. This should only
> ever be a temporary workaround like SUSPEND_MODULES.

If ondemand behaves sanely, I have no problem with the above change.

> 95led: Blink the suspend LED on IBM.
> It would be cool if thinkpad_acpi did this on its own, but I do
> appreciate the blinking on my thinkpad.
> 
> 90chvt, 99video: It would be great if these would die someday...

indeed.  Last time I profiled suspend/resume, these were the big time
wasters.  We can probably treat 90chvt more like a quirk (only chvt if
we have other video quirks to run, and let the kernel do a chvt if it
needs to, which it does right now.)  I have a patch that sorta
implements this behaviour -- chvt handling is moved to 99video and if
98smart-kernel-video detects a smart video driver, it disables chvt'ing.
I posted it to the list 4 - 5 months ago, but there was not much
interest.

> Any comments?

IIRC, 10NetworkManager is also redundant if gnome-power-manager is the
policy manager.

> --
> Dan
> _______________________________________________
> Pm-utils mailing list
> Pm-utils at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pm-utils
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019