Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760048Ab0FKBoK (ORCPT ); Thu, 10 Jun 2010 21:44:10 -0400 Received: from netrider.rowland.org ([192.131.102.5]:41651 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754052Ab0FKBoJ (ORCPT ); Thu, 10 Jun 2010 21:44:09 -0400 Date: Thu, 10 Jun 2010 21:44:06 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= cc: tytso@mit.edu, Alan Cox , Florian Mickler , Peter Zijlstra , Brian Swetland , "H. Peter Anvin" , LKML , Neil Brown , James Bottomley , Linux PM , Thomas Gleixner , Linux OMAP Mailing List , Linus Torvalds , Ingo Molnar , Felipe Balbi , Arjan van de Ven Subject: Re: [linux-pm] suspend blockers & Android integration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2967 Lines: 62 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/