Message-ID: <alpine.LFD.2.00.1006020905410.2933@localhost.localdomain>
Date:	Wed, 2 Jun 2010 10:29:14 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arve Hjønnevåg <arve@...roid.com>
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)

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. :)

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

Thanks,

	tglx

Powered by blists - more mailing lists