[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 Cox on 27 May 2010 18:00 On Thu, 27 May 2010 22:36:35 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote: > > On Thu, 27 May 2010 18:25:10 +0100 > > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > > 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 > > No it doesn't. The kernel continues executing anything that was on the Would you like to come and watch my laptop resume ? With printk's if you want. You appear at this point to be arguing that bumble bees can't fly, while watching one. > runqueue before the scheduler stopped. If you're using idle-based > suspend then there's nothing on the runqueue - the application that > should be scheduled because of the event is blocked on writing to the > screen. IFF its your bogus example IFF you don't have any task waiting for resume notifications (ie its not X) So take the PC desktop case and for simplicity sake lets assume the X application in question has either filled the socket (unlikely) or is mid query request so blocked on the socket. The important line then is 'The kernel lets interested people know a resume occurred' Interesting people includes X X therefore ends up on the runqueue X gets the display back in order X completes processing the outstanding X request and replies The application continues If I was blocked on say serial output then the resume is going to wake the serial driver, which will transmit the queue, which will wake the app. 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: Rafael J. Wysocki on 27 May 2010 18:00 On Thursday 27 May 2010, Alan Cox wrote: > > > 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. > > Yes I appreciate what suspend blockers are trying to do. Now how does > that connect with my first sentence ? I guess what Matthew wanted to say was that you couldn't use ACPI S3 as a very deep CPU idle state, because of the way wakeup sources are set up for it, while you could use it for aggressive power management with suspend blockers as proposed by Arve. Rafael -- 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 18:10 On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 22:36:35 +0100 > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > No it doesn't. The kernel continues executing anything that was on the > > Would you like to come and watch my laptop resume ? With printk's if you > want. You appear at this point to be arguing that bumble bees can't > fly, while watching one. The kernel performs no explicit notification to userspace. With legacy graphics setups you'll get a VT switch, but X is entirely unaware that that's due to suspend and that's going away in any case. On a typical setup it's not even the kernel that does the VT switch to and from X - that's handled by a script that happens to be on the runqueue. So yeah, things kind of work as you suggest right now - but only by accident, not design. What you're describing requires a new interface to inform interested bits of userspace whenever you transition from your deep idle state into a less deep one. -- 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 18:10 On Thu, 27 May 2010 17:38:03 -0400 (EDT) Alan Stern <stern(a)rowland.harvard.edu> wrote: > > and power management does the rest. If an event wakes up the process > > before we get to suspend in kernel we will wake it back up. > > Okay, and the kernel never suspends. We _are_ talking about a kind of > forced suspend, right? No ? We are talking about just letting power management solve the whole problem for us. > > If the event > > gets in after pm decides to idle via suspend then it'll bounce through > > the kernel back to a kernel resume, > > No, it won't. That's the problem suspend blockers were meant to solve. > The event winds up sitting in a kernel queue, the PM core doesn't know > about it (that's what I meant above -- the PM core doesn't know as much > as you seem to think it does), and the suspend takes place regardless. No - because we are not forcing the suspend. The app must go idle. If you force the suspend of running processes then yes the entire thing goes castors up - which is why it's a bad idea to do so. > > or potentially through a full > > hardware/software suspend/resume bounce. > > It would be okay if that happened. But once the event gets into the > kernel and the hardware IRQ source has turned off, there's nothing to > cause the resume. Read the discussion about how the race is avoided at the hardware level. That race is I think not there and furthermore most drivers get it right already. There are several cases 1. IRQ during app layer (ie policy in user space) asking applications to go passive - The event occurs, we undo the app layer policy, easy (or app wakes process and we let it fall through) 2. IRQ after the app layer quiesces its clients - The task wakes, the app layer won't see it - the app layer allows suspend as an idle mode. Not a problem - the app is running the cpu policy manager will see this and not suspend until the app has been asleep for a bit. The app may well of course tell the UI layer 'hey I want you back on' and it take you back to the full on case. 3. IRQ after kernel suspend begins - The driver will refuse the suspend, we don't suspend, we unwind the resume so far, the app wakes, we propogate stuff back up to user space whose policy manager unwinds its position 4. IRQ after driver has done its final checks - Wake up lines are set - We suspend - We immediately get resumed - We follow the full resume path This is I believe robust (and has been implemented on some non x86 boxes). It depends on not forcing running tasks into suspend. That is the key. 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: Alan Cox on 27 May 2010 18:20
On Thu, 27 May 2010 23:55:13 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > On Thursday 27 May 2010, Alan Cox wrote: > > > > 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. > > > > Yes I appreciate what suspend blockers are trying to do. Now how does > > that connect with my first sentence ? > > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as > a very deep CPU idle state, because of the way wakeup sources are set up > for it, while you could use it for aggressive power management with suspend > blockers as proposed by Arve. Which is a nonsense. Because the entire Gnome desktop and KDE, and OpenOffice and Firefox and friends would need fitting out with suspend blockers. x86 hardware is moving to fix these problems (at least on handheld devices initially). Look up the C6 power idle, and S0i1 and S0i3 standby states. I reckon the laptop folks can probably get the hardware fixed well before anyone can convert the entire PC desktop to include blockers. 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/ |