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:40 On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote: > > 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. So let them, doesn't mean we have to merge it. Or will you saw your foot off too if google were to promotes it? -- 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:40 On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: > > 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? Because the application that needs to handle the network packet is currently blocked trying to draw something to the screen. -- 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: Alan Stern on 27 May 2010 13:40 On Thu, 27 May 2010, Peter Zijlstra wrote: > 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: > > > 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? On some platforms (like those with ACPI), deeper power-savings are available by using forced suspend than by using idle. That used to be the case on Android. Arve has said that it isn't necessarily true any more, but that's the way their software is set up. 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:40 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. -- 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: Matthew Garrett on 27 May 2010 13:50
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: > > > Why would you care about the screen for a network event? > > > > Because the application that needs to handle the network packet is > > currently blocked trying to draw something to the screen. > > Then that's an application bug right there, isn't it? > > If should have listened to the window server telling its clients it was > going to go away. Drawing after you get that is your own damn fault ;-) How long do you wait for applications to respond that they've stopped drawing? What if the application is heavily in swap at the time? -- 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/ |