[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 14:00 On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote: > 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. Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system? -- 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 14:10 On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote: > > > Shall we henceforth stop confusing forced suspend for laptops and > > powersaving a running system? > > If you want to support forced suspend for laptops and you want to avoid > the risk of losing wakeups then you need in-kernel suspend blockers. > That's entirely orthogonal to Android's runtime power management. The simple fact of life is, on PC style hardware suspend is mostly about missing events. I really _really_ want to miss mouse movement of my bluetooth mouse when the gear is stowed in my backpack. Its perfectly OK to miss events on _forced_ suspend. -- 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 14:10 On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote: > > > Oh no. They paper over a short coming. If there is a pending event, > > the kernel knows that. It just does not make use of this > > information. Blockers just paper over this by sprinkling > > do_not_suspend() calls all over the place. What a sensible solution. > > Even if we could use suspend-via-deep-idle-state on PCs, we still need > to be able to enter suspend while the system isn't idle. There's two > ways to do that: > > 1) Force the system to be idle. Doing this race-free is difficult. > > 2) Enter suspend even though the system isn't idle. Since we can't rely > on the scheduler, we need drivers to know whether userspace has consumed > all wakeup events before allowing the transition to occur. Doing so > requires either in-kernel suspend blockers or something that's almost > identical. You're just not getting it. If user space has consumed the event is not relevant at all. What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters. Emptying your input queue is just the wrong indicator. And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway. And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed. The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise. 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: Peter Zijlstra on 27 May 2010 14:10 On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote: > > > How so, event happens on hardware level, IRQ gets raised, CPU wakes up, > > handler gets run, handler generates a task wakeup, runqueue isn't empty, > > we run stuff. > > If you're using idle-based suspend without any forced idling or blocking > of applications then you don't lose wakeups. People keep conflating > separate issues. I still don't see how blocking applications will cause missed wakeups in anything but a buggy application at worst, and even those will eventually get the event when they unblock. What seems to be the confusion? -- 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 14:20
On Thu, 27 May 2010, 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. That's the difference between opportunistic and enforced suspend. On enforced suspend the QoS guarantee is forced to NONE for everything and you go down no matter what. When you decide to push the wakeup button the system restores. 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/ |