Message-ID: <Pine.LNX.4.44L0.1006102126220.2585-100000@netrider.rowland.org>
Date:	Thu, 10 Jun 2010 21:44:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	tytso@....edu, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Florian Mickler <florian@...kler.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Brian Swetland <swetland@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
	James Bottomley <James.Bottomley@...e.de>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:

> >> For that to work the wakeup events would have to be reported to the
> >> power manager in a reliable way in the first place. Passing the file
> >> descriptor that the app uses to the power manager does not work for
> >> this, since the app could read the event while the power manager was
> >> not in the poll call and the power manager would never see it.
> >
> > If the app activates a suspend blocker before reading the event, this
> > doesn't matter.  If the app doesn't activate a suspend blocker then it
> > risks being suspended after it has read the event but before it has
> > handled the event.  This is equally true with wakelocks.
> >
> 
> It is not the same. Using a wakelock with a timeout only has a problem
> if the app did not get a change to run and block suspend before the
> timeout expires. With the timeout values we use there is only a
> problem if the system is already unresponsive. If the driver does not
> block suspend but instead a power manager calls select or poll on a
> file descriptor while the app does a blocking read, the power manager
> can easily miss the event and suspend before the app blocks suspend.

You've lost me.  If the power manager is sitting inside a select/poll, 
how can it miss the event (given that the event will make data 
available to be read on one of the descriptors being polled)?

Or put it another way: With wakelocks, if the app doesn't use a suspend
blocker then once it reads the event data and the timed wakelock is
deactivated, there is nothing to prevent the system from immediately
going into opportunistic suspend.  My scheme can fail in the same way.  
Is that what you meant?

> >> The suspend blocker approach is more generally useful since it
> >> supports hardware where suspend is needed. Why this argument is being
> >> ignored is very puzzling.
> >
> > Probably because people doesn't envision system suspend being used for
> > dynamic power management on that kind of hardware.
> >
> 
> I'm not sure what you mean by dynamic power management here (frequency
> of suspends?), but auto suspend is already in use on x86 desktops and
> laptops. Suspend blockers can fix the race with some wakeup events
> there.

You should stress this point more strongly when conversing with others.  
I doubt it will be enough to change anybody's mind, but it can't hurt.  
Indeed, if you propose suspend blockers as a way to fix a lost-wakeup 
bug in existing distributions, rather than as something needed to 
support Android, people might view it more favorably.


There's one question that I don't remember ever seeing answered.  To
which kernel drivers do you intend to add suspend blockers?

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