Message-ID: <AANLkTikz2UcDv6BZQ9Hq2MdowuAK1y_PBBPPXMEkDmNa@mail.gmail.com>
Date:	Mon, 24 May 2010 18:05:14 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	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.

2010/5/21 Alan Stern <stern@...land.harvard.edu>:
> On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:
>
>> The first goal can be achieved either by using device runtime PM and
>> cpuidle to put all hardware into low-power states, transparently from
>> the user space point of view, or by suspending the whole system.
>> However, system suspend, in its current form, does not guarantee that
>> the events of interest will always be responded to, since wakeup
>> events (events that wake the CPU from idle and the system from
>> suspend) that occur right after initiating suspend will not be
>> processed until another possibly unrelated event wakes the system up
>> again.
>
> Minor point of clarification here.  I'm not requesting that the patch
> description be rewritten.  But this issue of lost wakeup events is more
> subtle than it appears.
>
> Wakeup events can be lost in at least three different ways:
>
>     1. A hardware signal (such as an IRQ) gets ignored.
>
>     2. The hardware event occurs, but without effect since the
>        kernel thread that would handle the event has been frozen.
>        The event just ends up sitting in a queue somewhere until
>        something else wakes up the system.
>
>     3. The hardware event occurs and the kernel handles it fully,
>        but the event propagates to userspace for further handling
>        and the user program is already frozen.
>
> 1 is a hardware configuration failure (for example, it might happen as
> a result of using edge-triggered IRQs instead of level-triggered) and
> is outside the scope of this discussion.
>
> 2 generally represents a failure of the core PM subsystem, or a failure
> of some other part of the kernel to use the PM core correctly.  In
> theory we should be able to fix such mistakes.  Right now I'm aware of
> at least one possible failure scenario that could be fixed fairly
> easily.
>
> 3 is the type of failure that suspend blockers were really meant to
> handle, particularly the userspace suspend-blocker API.
>
> IMO, we should strive to fix the existing type-2 failure modes.
> However it is worth pointing out that they are basically separate from
> the suspend-blocker mechanism.
>
> And it might be a good idea to point out somewhere in the patch
> descriptions that suspend blockers are really meant to handle type-3
> wakeup losses.
>

I don't see a big difference between 2 and 3. You can use suspend
blockers to handle either.

-- 
Arve Hjønnevåg
--
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