[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 12:10 On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote: > > Now, if the user is playing this game, you want it to be scheduled. If > > the user has put down their phone and the screen lock has kicked in, you > > don't want it to be scheduled. So we could imagine some sort of cgroup > > that contains untrusted tasks - when the session is active we set a flag > > I would hope not, because I'd rather prefer my app that used the screen > to get the chance to save important data on what it was doing > irrespective of the screen blank: "I have an elegant proof for this > problem but my battery has gone flat" Perhaps set after callbacks are made. But given that the approach doesn't work anyway... > What is the problem here - your device driver for the display can block > tasks it doesn't want to use the display. It's still racy. Going back to my example without any of the suspend blocking code, but using a network socket rather than an input device: int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0); char foo; struct sockaddr addr; connect (input, &addr, sizeof(addr)) while (1) { if (read(input, &foo, 1) > 0) { (do something) } else { (draw bouncing cows and clouds and tractor beams briefly) } } A network packet arrives while we're drawing. Before we finish drawing, the policy timeout expires and the screen turns off. The app's drawing is blocked and so never gets to the point of reading the socket. The wakeup event has been lost. -- 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 12:20 > No. Suspend blockers are designed to ensure that suspend isn't racy with > respect to wakeup events. The bit that mitigates badly written > applications is the bit where the scheduler doesn't run any more. How does having applications taking blockers fix that - it makes it worse. They are now blocking the kernel doing the right job. > If you're happy with a single badly written application being able to > cripple your power management story, you don't need opportunistic And taking a suspend blocker isn't "crippling your power management" ??? > What /is/ the correct way to solve this problem when entering explicit > suspend states? How do you guarantee that an event has been delivered to > userspace before transitioning into suspend? Now, this is a less > interesting problem if you're not using opportunistic suspend, but it's > still a problem. The same way as we deal with low power states on other non PC devices ? > That's no good. If the input device has been deactivated, how does the > wakeup event get delivered to the application? If the input device is letting itself get de-activated in a way that can lose events the input device driver is buggy. It's nobody elses business how it does the its job, and certainly *not* the applications. That's a kernel internal issue. You know the resource constraint exists because the driver knows it is open Your QoS guarantees tell you what you desired latency of response at the point you can become ready is. That's all your need to do it right. In kernel yes your device driver probably does need to say things like 'Don't go below C6 for a moment' just as a high speed serial port might want to say 'Nothing over 10mS please' I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. So you need Userspace -> QoS guarantee expression, implied resource expression via device use. *NO* knowledge of device or platform in the application Kernel space Drivers -> Explicit guarantee expression not bound to tasks. Driver encapsulates the variety in the device hardware and expresses it in a uniform manner to the idling/suspend logic CPU Freq -> Encapsulates the variety in the CPU and core power functionality of devices, makes policy based upon the uniform express from the drivers and tasks All the autonomy is now in the right places, and we have requisite variety to actually manage the situation. 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 12:30 On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote: > I can't speak for Thomas, but I'm certainly not arguing that you don't > need something that looks more like the blocker side of the logic *in > kernel*, because there is stuff that you want to express which isn't tied > to the task. Sure, if you're not using opportunistic suspend then I don't think there's any real need for the userspace side of this. The question is how to implement something with the useful properties of opportunistic suspend without without implementing something pretty much equivalent to the userspace suspend blockers. I've sent another mail expressing why I don't think your proposed QoS style behaviour provides that. -- 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: Florian Mickler on 27 May 2010 12:30 On Thu, 27 May 2010 16:10:54 +0100 Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > The reality is you need a sane, generic, race free way to express your > requirements (eg for hard RT) and ditto for constraining the expression > (for 'crapplications') And the thing is, even a well written app can be a 'crapplication' depending on the context and mood of the user. cheers, Flo -- 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: Felipe Balbi on 27 May 2010 12:30
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: >If people don't mind, here is a greatly simplified summary of the >comments and objections I have seen so far on this thread: > > The in-kernel suspend blocker implementation is okay, even > beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. -- balbi DefectiveByDesign.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/ |