[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: Alan Stern on 27 May 2010 13:10 On Thu, 27 May 2010, Thomas Gleixner 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. This is where you are wrong. Maybe not wrong in principle, but wrong in practice -- the kernel's present suspend-to-RAM (or just "suspend") implementation is _very_ different from C-states (or just "idle"). The primary difference is that the kernel can be forced into suspend even when the system isn't idle. In particular, it may be in the middle of processing a potential wakeup event -- and the current design gives the PM core no way to know if that is so. This is a weakness that in-kernel suspend blockers fix. With C-states this can't happen. If the CPU goes into a deeper C-state then ipso facto it isn't busy processing anything, much less a wakeup event. Now maybe this difference is a bad thing, and the whole PM suspend/hibernate infrastructure should be rewritten. But the fact, remains, that's how it works now. And it can't be changed easily or quickly. 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: Thomas Gleixner on 27 May 2010 13:10 On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote: > > > I can't speak for Thomas, but I'm certainly not arguing that you don't > > need something that looks more like the blocker side of the logic *in > > kernel*, because there is stuff that you want to express which isn't tied > > to the task. > > Sure, if you're not using opportunistic suspend then I don't think > there's any real need for the userspace side of this. The question is > how to implement something with the useful properties of opportunistic > suspend without without implementing something pretty much equivalent to > the userspace suspend blockers. I've sent another mail expressing why I > don't think your proposed QoS style behaviour provides that. Opportunistic suspend is just a deep idle state, nothing else. If the overall QoS requirements allow to enter that deep idle state then the kernel goes there. Same decision as for all other idle states. You don't need any user space blocker for this decision, just sensible QoS information. Stop thinking about suspend as a special mechanism. It's not - except for s2disk, which is an entirely different beast. 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: Felipe Balbi on 27 May 2010 13:20 Hi, On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote: >Opportunistic suspend is just a deep idle state, nothing else. If the >overall QoS requirements allow to enter that deep idle state then the >kernel goes there. Same decision as for all other idle states. You >don't need any user space blocker for this decision, just sensible QoS >information. agree completely with you. Adding virtual differences between power states is a bad idea and causes unnecessary complication to the system. If we have a generic way of describing desired latencies (irq, wakeup, throughput, whatever), then the kernel should decide what's the best power state for the current situation. -- balbi DefectiveByDesign.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: Peter Zijlstra on 27 May 2010 13:20 On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > Sure, if you're not using opportunistic suspend then I don't think > > > there's any real need for the userspace side of this. The question is > > > how to implement something with the useful properties of opportunistic > > > suspend without without implementing something pretty much equivalent to > > > the userspace suspend blockers. I've sent another mail expressing why I > > > don't think your proposed QoS style behaviour provides that. > > > > Opportunistic suspend is just a deep idle state, nothing else. > > No. The useful property of opportunistic suspend is that nothing gets > scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? -- 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: Felipe Balbi on 27 May 2010 13:20
On Thu, May 27, 2010 at 07:04:24PM +0200, ext 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 >attention to latencies or other requirements. no, not at all. I think they are also really useful. But I also think in-kernel suspend blockers are unnecessary. I think runtime pm + cpuidle + cpufreq is well enough for all cases. We just need to give those three information about desired latencies. -- balbi DefectiveByDesign.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/ |