Message-ID: <AANLkTinDm3FIrbS1jqEzW15THmr1hdd7ox0Mllm1VLjZ@mail.gmail.com>
Date:	Wed, 2 Jun 2010 01:54:38 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Florian Mickler <florian@...kler.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

2010/6/2 Thomas Gleixner <tglx@...utronix.de>:
> On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
>> 2010/6/1 Thomas Gleixner <tglx@...utronix.de>:
>> > On Mon, 31 May 2010, Arve Hjønnevåg wrote:
>> >
>> >> 2010/5/31 Rafael J. Wysocki <rjw@...k.pl>:
>> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote:
>> >> >> 2010/5/30 Rafael J. Wysocki <rjw@...k.pl>:
>> >> > ...
>> >> >>
>> >> >> I think it makes more sense to block suspend while wakeup events are
>> >> >> pending than blocking it everywhere timers are used by code that could
>> >> >> be called while handling wakeup events or other critical work. Also,
>> >> >> even if you did block suspend everywhere timers where used you still
>> >> >> have the race where a wakeup interrupt happens right after you decided
>> >> >> to suspend. In other words, you still need to block suspend in all the
>> >> >> same places as with the current opportunistic suspend code, so what is
>> >> >> the benefit of delaying suspend until idle?
>> >> >
>> >> > Assume for a while that you don't use suspend blockers, OK?  I realize you
>> >> > think that anything else doesn't make sense, but evidently some other people
>> >> > have that opinion about suspend blockers.
>> >> >
>> >>
>> >> It sounded like you were suggesting that initiating suspend from idle
>> >> would somehow avoid the race condition with wakeup events. All I'm
>> >> saying is that you would need to block suspend in all the same places.
>> >> If you don't care about ignoring wakeup events, then sure you can
>> >> initiate suspend from idle.
>> >
>> > And why should you miss a wakeup there ? If you get an interrupt in
>> > the transition, then you are not longer idle.
>> >
>>
>> Because suspend itself causes you to not be idle you cannot abort
>> suspend just because you are not idle anymore.
>
> You still are addicted to the current suspend mechanism. :)
>

No I want you to stop confusing low power idle modes with suspend. I
know how to enter low power modes from idle if that low power mode is
not too disruptive.

> The whole point of doing it from idle in the form of a deep power
> state is to avoid the massive sh*tload of work which is neccesary to
> run the existing suspend code. But that needs runtime power management
> and tweaks to avoid your timers waking you, etc.
>
> The mechanism you want to use is: suspend no matter what, like closing
> the lid of the laptop, but with a few tweaks around it:
>
>   1) An interrupt on a wakeup source which comes in while the suspend
>      code runs, i.e before you transitioned into wakeup mode, must
>      abort / prevent suspend.
>
>   2) Prevent another attempt to suspend before the event has been
>      delivered and the apps have signaled that they have not longer
>      any work to do.
>
>   As a side effect you confine crappy apps with that mechanism in
>   some way.
>
> In the laptop case we do not want the tweaks as not going into suspend
> might set your backpack on fire.

If that is the case you should also disable the wakeup events.

>
> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
>
>    1) crappy applications keeping the cpu away from idle
>    2) timers firing
>
> Would solving those two issues be sufficient for you or am I missing
> something ?

Solving those two is enough for current android phones, but it may not
be enough for other android devices. 1 is not solvable (meaning we
cannot fix all apps), and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way
to solve 2 is to allow timers on a not-idle clock. Unrelated to
Android, I also want to use opportunistic suspend on my desktop.

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