[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Rafael J. Wysocki on 31 May 2010 17:50 On Monday 31 May 2010, Arve Hj�nnev�g wrote: > 2010/5/30 Rafael J. Wysocki <rjw(a)sisk.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. Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend. Rafael -- 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: Thomas Gleixner on 31 May 2010 17:50 On Mon, 31 May 2010, James Bottomley wrote: > > For MSM hardware, it looks possible to unify the S and C states by doing > suspend to ram from idle but I'm not sure how much work that is. On ARM, it's not rocket science and we have in tree support for this already (OMAP). I have done the same thing on a Samsung part as a prove of concept two years ago and it's really easy as the hardware is sane. Hint: It's designed for mobile devices :) Thanks, tglx -- 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: Thomas Gleixner on 31 May 2010 17:50 On Sat, 29 May 2010, James Bottomley wrote: > On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote: > > > > Not using suspend is exactly the point. As Alan has argued, propagating > > suspend blockers up into all regions of userspace will take much longer > > than fixing the hardware. > > Strange, that's not what I heard as the possible solution. I thought he > was advocating expressing the kernel side of suspend blockers as QoS > constraints. Once we have QoS constraints correctly done in the kernel, > userspace still has to express its requirements. If the requirements > are static, then they can be done from policy files or in some other > static way but if they're dynamic, they'll still have to be in the > applications ... in about the same places the android wakelocks are. That's wrong. You only need the explicit dynamic QoS constraints for applications which follow the scheme: while (1) { if (event_available()) process_event(); else do_useless_crap_which_consumes_power(); } which need the following annotation: while (1) { block_suspend(); if (event_available()) { process_event(); unblock_suspend(); } else { unblock_suspend(); do_useless_crap_which_consumes_power(); } } Plus the kernel counterpart of drivers which take the suspend blocker in the interrupt handler and release it when the event queue is empty. So that's done for making polling event handling power "efficient". Even worse, you need the same "annotation" for non polling mode and it enforces the use of select() because you cannot take a suspend blocker across a blocking read() without adding more invasive interactions to the kernel.. So the "sane" app looks like: while (1) { select(); block_suspend(); process_events(); unblock_suspend(); } I'm really tired of arguing that this promotion of "programming style" is the worst idea ever, so let's look how you can do the same thing QoS based. s/block_suspend()/qos(INTERACTIVE)/ and s/unblock_suspend()/qos(NONE)/ and s/block_magic()/qos_magic()/ in the drivers. Yes, it's mostly the same, with a subtle difference: While android can use it in the big hammer approach to disable the existing user initiated suspend via /sys/power/state, the rest of the world can benefit as well in various ways. - Sane applications which use a blocking event wait can be handled with a static QoS setting simply because a blocking read relies on the QoS state of the underlying I/O system. - Idle based suspend as the logical consequence of idle states is just a matter of QoS constraint based decisions. - Untrusted apps can be confined in cgroups. The groups are set to QoS(None) when user land decides that it's time to safe power (e.g. screen lock kicks in) - QoS states can block applications from I/O when the I/O system is set to a state which is exclusive. - ... So that allows to use the same mechanism for more than the android sledge hammer approach and confines the controversial use cases into android specific files without adding a hard to maintain user space interface which would prevent or at least make it hard to do some of the above mentioned things which we want to see implemented. While I personally disagree with the android approach, I REALLY want to provide them a mechanism to make it work, but not for the price that it actively prevents solutions which are considered to be technically superior by a relevant group of developers/maintainers. > > You got to realize this is about Linux as a whole, I really don't care > > one whit about the specific Android case. We want a solution that is > > generic enough to solve the power consumption problem and makes sense on > > future hardware. > > I don't think anyone disagrees with this. As long as we find a long term > solution that satisfies the android case, everyone will be happy. See above. Thanks, tglx -- 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: Rafael J. Wysocki on 31 May 2010 18:10 On Monday 31 May 2010, Neil Brown wrote: > On Thu, 27 May 2010 23:40:29 +0200 (CEST) > Thomas Gleixner <tglx(a)linutronix.de> wrote: > > > On Thu, 27 May 2010, Rafael J. Wysocki wrote: > > > > > On Thursday 27 May 2010, Thomas Gleixner wrote: > > > > On Thu, 27 May 2010, Alan Stern wrote: > > > > > > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > > > > >If people don't mind, here is a greatly simplified summary of the > > > > > > >comments and objections I have seen so far on this thread: > > > > > > > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > > > > beneficial. > > > > > > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > > > > the kernel decide which power state is better as long as I can say I > > > > > > need 100us IRQ latency or 100ms wakeup latency. > > > > > > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and > > > > > should be removed? Or "echo disk >/sys/power/state"? They pay no > > > > > > > > mem should be replaced by an idle suspend to ram mechanism > > > > > > Well, what about when I want the machine to suspend _regardless_ of whether > > > or not it's idle at the moment? That actually happens quite often to me. :-) > > > > Fair enough. Let's agree on a non ambigous terminology then: > > > > forced: > > > > suspend which you enforce via user interaction, which > > also implies that you risk losing wakeups depending on > > the hardware properties > > Reasonable definition I think. However the current implementation doesn't > exactly match it. > With the current implementation you risk losing wakeups *independent* of the > hardware properties. Define "losing", please. Currently, we simply don't regard hardware signals occuring _during_ the suspend operation itself as wakeups (unless they are wakeup interrupts to be precise, because these _are_ taken into account by our current code). The reason is that the meaning of given event may be _different_ at run time and after the system has been suspended. For example, consider a power button on a PC box. If it's pressed at run time, it usually means "power off the system" to the kernel. After the system has been suspended, however, it means "wake up". So, you have to switch from one interpretation of the event to the other and that's not an atomic operaition (to put it lightly). > Even with ideal hardware events can be lost - by which I mean that they will > not be seen until some other event effects a wake-up. > e.g. the interrupt which signals the event happens immediately before the > suspend is requested (or maybe at the same time as), but the process which > needs to handle the event doesn't get a chance to see it before the suspend > procedure freezes that process, and even if it did it would have no way to > abort the suspend. > > So I submit that the current implementation doesn't match your description of > "forced", is therefore buggy, and that if it were fixed, that would be > sufficient to meet the immediate needs of android. I don't really think it may be fixed with respect to every possible kind of hardware. On platforms where I/O interrupts are wakeup events it should work right now. On other platforms it may be impossible to overcome hardware limitations. Thanks, Rafael -- 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: Thomas Gleixner on 31 May 2010 18:20
On Mon, 31 May 2010, James Bottomley wrote: > On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote: > > On Sat, 29 May 2010, James Bottomley wrote: > > > The job of the kernel is to accommodate hardware as best it can ... > > > sometimes it might not be able to, but most of the time it does a pretty > > > good job. > > > > > > The facts are that C states and S states are different and are entered > > > differently. > > > > That's an x86'ism which is going away. And that's really completely > > irrelevant for the mobile device space. Can we please stop trying to > > fix todays x86 based laptop problems? They are simply not fixable. > > You're the one mentioning x86, not me. I already explained that some > MSM hardware (the G1 for example) has lower power consumption in S3 > (which I'm using as an ACPI shorthand for suspend to ram) than any > suspend from idle C state. Those machines can go from idle into S2RAM just fine w/o touching the /sys/power/state S2RAM mechanism. It's just a deeper "C" state, really. The confusion is that S3 is considered to be a complete different mechanism - which is true for PC style x86 - but not relevant for hardware which is sane from the PM point of view. Now some people think, that suspend blockers are a cure for the existing x86/ACPI/BIOS mess, which cannot go to S3 from idle, but that's simply not feasible. Thanks, tglx -- 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/ |