Date:	Wed, 26 May 2010 09:59:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Arve Hjønnevåg <arve@...roid.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	<linux-doc@...r.kernel.org>
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > How is that not polling? If the user is holding down a key, the keypad
> > driver has to block suspend, and user space will try to suspend again
> > and again and again...
> > 
> 
> If your userpsace is that stupid - sure. However, you can:
> 
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.
> 
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.

This is more complicated than necessary.  Arve is wrong; my suggested 
design does not require polling.

The reason is simple: When a user process initiates an opportunistic 
suspend, you make it wait in an interruptible sleep until all the 
kernel suspend blockers are released.  No polling.  If another user 
thread decides in the meantime that it needs to block the suspend, it 
sends a signal to the power manager process.

In fact, other threads should signal the power manager process whenever 
they want to block or unblock suspends.  That way the power manager 
process can spend all its time sleeping, without doing any polling.

> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.
> 
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.

That's not so easy.  The design of the PM core requires that when the 
system wakes up from suspend (or from an aborted suspend attempt), all 
devices should go to full-power-on.  This is explained in section 6 of
Documentation/power/runtime_pm.txt.

The decision over whether to use kernel-space suspend blockers vs. 
aborting suspends when queues are non-empty comes down to a tradeoff:

	Suspend blockers involve a little more code (to create,
	destroy, enable, and disable them) plus a little extra
	runtime overhead each time an event occurs.  (Some people
	may object to this extra overhead, although so far nobody
	in this discussion has done so.)

	Suspend blockers eliminate the extra overhead involved in
	starting suspends that are just going to be aborted.

	Suspend blockers offer extra debugging and accountability
	(the user can find out which subsystems are responsible for
	keeping the system awake).

Which way you think the tradeoff should go is a subjective decision.  I 
think that kernel suspend blockers are acceptable.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists