[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 14:20 On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote: > > 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. That's fine - those shouldn't be configured as wakeup events. > Its perfectly OK to miss events on _forced_ suspend. No, it's not. Forced suspend may be in response to hitting a key, but it may also be in response to a 30 minute timeout expiring. If I get a WoL packet in the 0.5 of a second between userspace deciding to suspend and actually doing so, the system shouldn't suspend. -- 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: Thomas Gleixner on 27 May 2010 14:20 On Thu, 27 May 2010, Matthew Garrett wrote: > 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? Very realistic scenario on a mobile phone. -- 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 14:20 On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote: > I'd prefer we avoided mixing them up. Everyone seems fairly happy with > the current operator ordered suspend behaviour I believe ? No. The current mechanism can lose wakeup events. -- 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 Cox on 27 May 2010 14:20 > > So PCs with current ACPI don't get opportunistic suspend capability. It > > probably won't be supported on the Commodore Amiga either - your point ? > > Actually, the reverse - there's no terribly good way to make PCs work > with scheduler-based suspend, but there's no reason why they wouldn't > work with the current opportunistic suspend implementation. If one works so does the other. > In some cases, not all. It may be a latency constraint (in which case > pm_qos is an appropriate mechanism), but instead it may be something > like "A key was pressed but never read" or "A network packet was > received but not delivered". These don't fit into the pm_qos model, but > it's state that you have to track. I never mentioned pm_qos, just latency *and* knowing what suspend states are acceptable. You need both. 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: Matthew Garrett on 27 May 2010 14:20
On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: > > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: > > > > > > > If that's what you're aiming for then you don't need to block > > > > applications on hardware access because they should all already have > > > > idled themselves. > > > > > > Correct, a well behaved app would have. I thought we all agreed that > > > well behaved apps weren't the problem? > > > > Ok. So the existing badly-behaved application ignores your request and > > then gets blocked. And now it no longer responds to wakeup events. > > It will, when it gets unblocked from whatever thing it got stuck on. It's blocked on the screen being turned off. It's supposed to be reading a network packet. How does it ever get to reading the network packet? -- 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/ |