[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: Peter Zijlstra on 27 May 2010 13:50 On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: > > > we still need to be able to enter suspend while the system isn't idle. > > > > _WHY_!? > > Because if I'm running a kernel build in a tmpfs and I hit the sleep > key, I need to go to sleep. Blocking processes on driver access isn't > sufficient. But that's a whole different issue. I agree that a forced suspend for things like that make sense, just not for power managing a running system. PC style hardware like that doesn't wake up from suspend for funny things like a keypress either (good thing too). Anyway all that already works (more or less), so I don't see the problem. -- 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: Alan Cox on 27 May 2010 13:50 > What is a "Correctly implemented driver" in this case? One that receives > a wakeup event and then prevents suspend being entered until userspace > has acknowledged that event? Because that's what an in-kernel suspend > blocker is. Kernel side maybe - but even then its a subset of expressing latency/lowest level requirements. That bit isn't really too contentious. You need a kernel object to hang a constraint off. > ACPI provides no guarantees about what level of hardware functionality > remains during S3. You don't have any useful ability to determine which > events will generate wakeups. And from a purely practical point of view, > since the latency is in the range of seconds, you'll never have a low > enough wakeup rate to hit it. So PCs with current ACPI don't get opportunistic suspend capability. It probably won't be supported on the Commodore Amiga either - your point ? > Suspend blockers are the mechanism for the > driver to indicate whether the wakeup event has been handled. That's > what they're there for. The in-kernel ones don't paper over anything. Semantically the in kernel blockers and the in kernel expression of device driven constraints are the same thing except that instead of yes/no you replace the boolean with information. So we go from block_suspend() / unblock_suspend() to add_pm_constraint(latency, level) remove_pm_constraint(latency, level); And if Android choses to interpret that in its policy code as if (latency > MAGIC) suspend_is_cool(); else suspend_isnt_cool(); that's now isolated in droidspace policy Alan -- 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: Florian Mickler on 27 May 2010 13:50 On Thu, 27 May 2010 19:25:27 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote: > > On Thu, 27 May 2010 18:45:25 +0200 (CEST) > > Thomas Gleixner <tglx(a)linutronix.de> wrote: > > > > > The whole notion of treating suspend to RAM any different than a plain > > > idle C-State is wrong. It's not different at all. You just use a > > > different mechanism which has longer takedown and wakeup latencies and > > > requires to shut down stuff and setup extra wakeup sources. > > > > > > And there is the whole problem. Switching from normal event delivery > > > to those special wakeup sources. That needs to be engineered in any > > > case carefuly and it does not matter whether you add suspend blockers > > > or not. > > > > Ok, I just don't know the answer: How is it just another idle state if > > the userspace gets frozen? Doesn't that bork the whole transition and > > you need a userspace<->kernel synchronisation point to not loose events? > > There is no userspace to freeze when the runqueues are empty. If in the imaginery situation where userspace can aquire certain wakeup-constraints and loose certain wakeup-constraints, then it could be that the system enters suspend without empty runqueues. > And as explained, you won't loose events if all the devices do a proper > state transition. To quote: I believe the problem beeing userspace frozen at an unopportune time. So the wakeup event is processed (kernel-side) but userspace didn't have time to reacquire the correct wakeup-constraint to process the event. I.e. the wakeup will be effectivly ignored. Cheers, Flo -- 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: Alan Stern on 27 May 2010 13:50 On Thu, 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote: > > > Even if we could use suspend-via-deep-idle-state on PCs, > > ( see Alan Cox's argument on PCs ) > > > we still need to be able to enter suspend while the system isn't idle. > > _WHY_!? You close your laptop's lid and throw the machine into a backpack. At that time you want it to suspend even though it may not be idle. > We've been trying to tell you you don't need that. And I'm trying to tell you that you do. Alan Stern -- 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: Alan Stern on 27 May 2010 13:50
On Thu, 27 May 2010, Thomas Gleixner wrote: > > 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 In other words, you are suggesting that not only should the Android patches not be accepted, in addition a large part of the PM suspend framework should be rewritten? Alan Stern -- 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/ |