Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Arve Hjønnevåg on 11 May 2010 21:20 2010/5/10 Kevin Hilman <khilman(a)deeprootsystems.com>: > Hello, > > I think many folks are still confused about exactly the problem being > solved by this series as well as mixed up between opportunistic > suspend and suspend blockers. �Also, how this series impatcs the rest > of the kernel (especially PM-aware drivers and subsystems) has caused > a bit of confusion. > > To help with the confusion, I think a much clearer description of the > problem being solved and the proposed solution is needed. > > To that end, I created a starting point for that below which > summarizes how I understand the problem and the proposed solution, but > of course this should be filled out in more detail and updated as part > of the documentation that goes with this series. > > Hope this helps improve the understanding of this feature, > > Kevin > > > > Table of Contents > ================= > 1 Problem Statement > 2 Solution: Opportunistic suspend > � �2.1 When to use a suspend blocker > � �2.2 Usage in PM aware drivers > > > 1 Problem Statement > ~~~~~~~~~~~~~~~~~~~~ > > Want to to hit deep power state, even when the system is not actually > idle. > > Why? > > - some hardware is not capable of deep power states in idle > - difficulty getting userspace and/or kernel to be idle There are two parts to this. Suspend freezes tasks that don't idle at all, and it stops the monotonic clock which in turn stops tasks that do (frequent) periodic work. > > 2 Solution: Opportunistic suspend > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Create an additional "idle path" which has new rules for determining > idleness. �When this new "idle" is reached, trigger full-system > suspend. �Since a suspend is triggered whenever the opportunity > arises, this is called opportunistic suspend. > > The new rules for making the idleness decision are simple: > > 1. �system may suspend if and only if no suspend blockers are held > > 2.1 When to use a suspend blocker > ================================== > > [A list of reasons why suspend blockers might be used would be very > �helpful here.] > > - ensure wakeup events propagate to userspace (e.g. keypad example in doc) > > - screen is on > > - someone mentioned "Google use cases" > �(would be nice to hear about more of these) Most uses of suspend blockers are in some way tied to a potential wakeup event. We use (a) suspend blocker(s) to make sure the event propagates to the code that will handle the event, and that code then uses another suspend blocker while it handles the event. Some examples: The battery monitor on Nexus One uses a periodic alarm to wake up the system. The alarm driver will block suspend so the timer can fire, and the battery monitor will block suspend while reading the battery status and changing the charge mode. Phone rings: We use a few suspend blockers to process the low level message from the modem which end up returning a message on a tty. The last step in the kernel currently uses a wakelock with a timeout since we have not modified the tty layer to block suspend. The user space ril process then blocks suspend while it handles this message. USB: We get a (wakeup) message from the modem that there is power on the usb connector and we block suspend while we detect what is connected. If we are connected to a USB host, we block suspend and turn on the usb interface. > > 2.2 Usage in PM aware drivers > ============================== > > [An example of how a driver already using runtime PM would use > �a suspend blocker would also be helpful. > An audio driver can block suspend while audio is playing. We don't currently use the runtime pm framework since this is new, but we do runtime pm by turning off clocks and power when the device is inactive. -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 12 May 2010 07:30 On Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote: > > 2.2 Usage in PM aware drivers > > ============================== > > [An example of how a driver already using runtime PM would use > > ?a suspend blocker would also be helpful. > An audio driver can block suspend while audio is playing. We don't > currently use the runtime pm framework since this is new, but we do > runtime pm by turning off clocks and power when the device is > inactive. Could you clarify what's going on here please? What do you mean by an "audio driver" here - there's several different classes of driver which work together to produce the embedded audio subsystem and I'm not clear which you're referring to here. I'd not expect a chip-specific audio driver to be taking suspend blockers at all except during things like accessory detect handling which can take a long time. A system-specific driver could reasonably block during playback but doing it in a chip specific driver sounds like a bit too much of a policy decision. The kernel runtime PM framwwork tends not to come into play for anything except MFD and SoC drivers with audio where they're a component of PM on the larger chip and it's useful for coordinating with the other drivers in play. Otherwise we already have very detailed automatic power management (especially for the CODECs) and there's no benefit in bouncing through runtime PM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 24 May 2010 15:00 Hi! > I agree that the runtime scenario is a far more appealing one from an > aesthetic standpoint, but so far we don't have a very compelling > argument for dealing with the starting and stopping of userspace. The > use-cases that Google have provided are valid and they have an > implementation that addresses them, and while we're unable to provide an > alternative that provides the same level of functionality I think we're > in a poor position to prevent this from going in. Uhuh? "We have this ugly code here, but it works and we don't have better one, so lets merge it"? I don't really like this line of reasoning. I would not want to judge wakelocks here, but... "it works, merge it" should not be used as argument. And btw I do have wakelock-less implementation of autosleep, that only sleeped the machine when nothing was ready to run. It was called "sleepy linux". Should I dig it out? Major difference was that it only sleeped the machine when it was absolutely certain machine is idle and no timers are close to firing -- needing elimination or at least markup of all short timers. It erred on side of not sleeping the machine when it would break something. Still I believe it is better design than wakelocks -- that need markup/fixes to all places where machine must not sleep -- effectively sleeping the machine too often than fixing stuff with wakelocks all over kernel and userspace... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 24 May 2010 15:10 On Mon, May 24, 2010 at 08:57:54PM +0200, Pavel Machek wrote: > And btw I do have wakelock-less implementation of autosleep, that only > sleeped the machine when nothing was ready to run. It was called > "sleepy linux". Should I dig it out? As has been explained several times now, that's not equivalent. The difference is what makes this a hard problem. If a usecase is valid and nobody can come up with a convincing explanation of what an elegant solution would look like, then the ugly solution wins. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 24 May 2010 21:20
On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel(a)ucw.cz> wrote: > Hi! > >> I agree that the runtime scenario is a far more appealing one from an >> aesthetic standpoint, but so far we don't have a very compelling >> argument for dealing with the starting and stopping of userspace. The >> use-cases that Google have provided are valid and they have an >> implementation that addresses them, and while we're unable to provide an >> alternative that provides the same level of functionality I think we're >> in a poor position to prevent this from going in. > > Uhuh? > > "We have this ugly code here, but it works and we don't have better > one, so lets merge it"? > > I don't really like this line of reasoning. I would not want to judge > wakelocks here, but... "it works, merge it" should not be used as > argument. > > And btw I do have wakelock-less implementation of autosleep, that only > sleeped the machine when nothing was ready to run. It was called > "sleepy linux". Should I dig it out? > > Major difference was that it only sleeped the machine when it was > absolutely certain machine is idle and no timers are close to firing > -- needing elimination or at least markup of all short timers. It > erred on side of not sleeping the machine when it would break > something. > How did you handle external events that occur right after you decided to sleep? > Still I believe it is better design than wakelocks -- that need > markup/fixes to all places where machine must not sleep -- effectively > sleeping the machine too often than fixing stuff with wakelocks all > over kernel and userspace... -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |