[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:20 On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote: > 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. Please re-read Thomas' description of how a driver should do the state transition. So either we get the packet before suspend, and we cancel the suspend, or we get it after and we wake up. What's the problem, and how does that need suspend blockers? -- 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:30 On Thu, May 27, 2010 at 07:17:16PM +0100, Alan Cox wrote: > > 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. Not at all. The entire point of opportunistic suspend is that I don't care is currently in TASK_RUNNABLE or has a timer that's due to expire in 100msec - based on policy (through not having any held suspend blockers), I'll go to sleep. That's easily possible on PCs. -- 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 14:30 On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > 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. > > How does that solve the problems you mentioned above ? Wakeup > guarantees, latencies ... Latency doesn't matter because we don't care when the next timer is due to expire. Wakeup guarantees can be provided via the suspend blocker implementation. -- 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: Peter Zijlstra on 27 May 2010 14:30 On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote: > 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? Its blocked because its a buggy app, who cares about misbehaviour in a buggy app? If it were a proper app it wouldn't have gotten blocked and would've been able to receive the network packet. I thought we'd already been over this? -- 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:30
On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote: > > > ACPI provides no guarantees about what level of hardware functionality > > > remains during S3. You don't have any useful ability to determine which > > > events will generate wakeups. And from a purely practical point of view, > > > since the latency is in the range of seconds, you'll never have a low > > > enough wakeup rate to hit it. > > > > 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. How does that solve the problems you mentioned above ? Wakeup guarantees, latencies ... It's not a prove of the technical correctness of the approach if it can provide a useless functionality. 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/ |