[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: Matthew Garrett on 27 May 2010 13:20 On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: > > 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? Because you may then block them in such a way that they never handle an event that should wake them. -- 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: Florian Mickler on 27 May 2010 13:30 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? 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: Peter Zijlstra on 27 May 2010 13:30 On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote: > > > Suppose X (or whatever windowing system) will block all clients that try > > to draw when you switch off your screen. > > > > How would we not wake them when we do turn the screen back on and start > > servicing the pending requests again? > > How (and why) does the WoL (which may be *any* packet, not just a magic > one) turn the screen back on? Why would you care about the screen for a network event? -- 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:30 On Thu, 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 13:04 -0400, Alan Stern 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 > > attention to latencies or other requirements. > > Those are a whole different beast, those are basically a quick-off > button like thing. Forced suspend is conceptually a very different beast > from power-saving a running system. They may be different conceptually. Nevertheless, Android uses forced suspend as a form of power saving. Until better mechanisms are in place, it makes sense. 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: Matthew Garrett on 27 May 2010 13:30
On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote: > > > 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. > > Nothing gets scheduled in a deep idle state either - its idle. We leave > the idle state to schedule anything. Certainly, if you can force the system to be idle then you don't need opportunistic suspend. But you haven't shown how to do that without it being racey. -- 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/ |