[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: Alan Stern on 27 May 2010 17:30 On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > A wakeup event is defined as one that wakes the system - if a system > > > can't be woken by a specific event then it's impossible to lose it, > > > since it wasn't a wakeup event to begin with. > > > > So where is the problem ? > > The problem is that, right now, if a wakeup event is received between > the point where userspace decides to start a suspend and userspace > actually starts a suspend, that event may not abort the suspend. The two of you are talking at cross purposes. Thomas is referring to idle-based suspend and Matthew is talking about forced suspend. Or at least, that's how it appears to me. No wonder you can't agree on anything. 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: Alan Cox on 27 May 2010 17:30 > Well, what about when I want the machine to suspend _regardless_ of whether > or not it's idle at the moment? That actually happens quite often to me. :-) I don't think it helps to combine them for this discussion ? > I don't see much difference between that and ACPI S3 other than the memory > contents are preserved in S3. It also is complete power off state - except for > memory refresh and wakeup sources (which also may be active in S4). Agreed although I am pushed to think of many real world cases where it might matter. VM's maybe? 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 17:40 On Thu, May 27, 2010 at 11:33:32PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > The two of you are talking at cross purposes. Thomas is referring to > > idle-based suspend and Matthew is talking about forced suspend. > > Yes, and forced suspend to disk is the same as force suspend to disk, > which has both nothing to do with sensible resource management. It doesn't matter. Current forced suspend to RAM is racy with respect to wakeup events and should be fixed. -- 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 17:40 On Thu, 27 May 2010 18:25:10 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> 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? Well on my laptop today it works like this A WoL packet arrives The CPU resumes Depp process, chipset and laptop BIOS magic happens The kernel gets called The kernel lets interested people know a resume occurred The X server sees this X reconfigures the display X redraws the display (either by sending everyone expose events or by keeping the bits, not sure how it works this week as it has changed over time) My desktop re-appears 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: Thomas Gleixner on 27 May 2010 17:40
On Thu, 27 May 2010, Alan Stern wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote: > > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > > A wakeup event is defined as one that wakes the system - if a system > > > > can't be woken by a specific event then it's impossible to lose it, > > > > since it wasn't a wakeup event to begin with. > > > > > > So where is the problem ? > > > > The problem is that, right now, if a wakeup event is received between > > the point where userspace decides to start a suspend and userspace > > actually starts a suspend, that event may not abort the suspend. > > The two of you are talking at cross purposes. Thomas is referring to > idle-based suspend and Matthew is talking about forced suspend. Yes, and forced suspend to disk is the same as force suspend to disk, which has both nothing to do with sensible resource management. 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/ |