[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: Florian Mickler on 27 May 2010 07:00 On Wed, 26 May 2010 10:38:50 -0400 (EDT) Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Wed, 26 May 2010, Florian Mickler wrote: > > > I don't think that the in-kernel suspend block is a bad idea. > > > > You could probably use the suspend-blockers unconditionally in the > > suspend framework to indicate if a suspend is possible or not. > > That's not how it works. Drivers aren't supposed to abort > unconditional suspend -- not without a really good reason (for example, > the device received a wakeup event before it was fully suspended). In > short, suspends should be considered to be _always_ possible. > > > Regardless of opportunistic suspend or not. This way, you don't have to > > try-and-fail on a suspend request and thus making suspending > > potentially more robust or allowing for a "suspend as soon as > > possible" semantic (which is probably a good idea, if you have to grab > > your laptop in a hurry to get away). > > That's different. Suspend blockers could block (not abort!) regular > suspends, just as they do opportunistic suspends. > > But why should they? I mean, if userspace wants to initiate a suspend > that is capable of being blocked by a kernel suspend blocker, then all > it has to do is initiate an opportunistic suspend instead of a normal > suspend. > > Alan Stern Let me elaborate what i mean: The assumption beeing that specifying pm constraints in the drivers is a good thing which we will be doing anyway in the long run. (See Alan Cox's summary of current mainline problems[1].) I don't wanna go into specifing any constraint API here, but it could probably be either a blocker flag (the here presented suspend-blocker, which Alan doesnt like?) or maybe a few integer-typed constraints defined by the pm-core. (needed scheduler-latency/needed io-latency?) As an intermediate step, it would probably be possible to specify the "I cant be suspended" constraint (aka blocker) for all drivers not explicitly stating anything other. Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any "no suspend" (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) A future switch from something like a flag (blocker) to a full integer-typed requirement would probably be a simple search and replace or even possible by extending the blocker-api. If that is done, the prototype of the driver callback int suspend(); could probably be changed to void suspend(); and it be expected to always _successfully_ suspend. The hard part is finding the places where special guarantees are needed. But android did show that this is possible. Cheers, Flo [1]: http://lkml.org/lkml/2010/5/26/575 -- 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: Igor Stoppa on 27 May 2010 08:10 ext Florian Mickler wrote: > > Converting a driver to using any constraint-API would require analysing > what makes a driver refuse suspending in the old suspend handler and > then specify any "no suspend" (or whatever) constraint before those > conditions arise and clearing of the constraints when it is no longer critical. > (Much work.) > That's not really true. Nothing prevents using from the beginning a sane approach where drivers are required to specify constraints. The way it has been done for the N900 was to let driver developers specify _very_ conservative constraints, during the conversion phase. Then each driver has been optimized. If you have as requirement for driver developers that their driver must be working properly when compiled as module, it is possible to test the system with a minimalistic kernel which enters the lowest power state as soon as possible, plus only those modules that are being optimized. This allows also to identify parasitic drivers, which fail to apply the proper constraint and instead rely on some other driver to keep the system alive. igor -- 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 09:30 On Wed, 26 May 2010, Alan Cox wrote: > > The power efficiency of a mobile device is depending on a sane overall > > software stack and not on the ability to mitigate crappy software in > > some obscure way which is prone to malfunction and disappoint users. > > Even if you believe the kernel should be containing junk the model that > works and is used for everything else is resource management. Not giving > various tasks the ability to override rules, otherwise you end up needing > suspend blocker blockers next week. We definitely will need them when we want to optimize the kernel resource management on a QoS based scheme, which is the only sensible way to go IMNSHO. > A model based on the idea that a task can set its desired wakeup > behaviour *subject to hard limits* (ie soft/hard process wakeup) works > both for the sane system where its elegantly managing hard RT, and for > the crud where you sandbox it to stop it making a nasty mess. Right, the base system can set sensible defaults for "verified" apps, which will work most of the time except for those which have special requirements and need a skilled coder anyway. And for the sandbox crud the sensible default can be "very long time" and allow the kernel to ignore them at will. > Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the > trick ? That might be a good starting point. 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/
From: Matthew Garrett on 27 May 2010 10:10 On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote: > - Supporting Android needs well good > - Opportunistic suspend good > - Manner in which interface is expressed to userspace bad > - Latency constraint interface would be better > - Your existing behaviour can be implemented by a simplistic use of a > latency constraint interface > - We can fix a pile of other directly connected things at the same time > - Implementation internals I care far less about because we can fix those > later > - Suspend is just a power state > > How does that fit your model and vision ? I don't entirely see how this works. In order to deal with poorly written applications, it's necessary to (optionally, based on some policy) ignore them when it comes to the scheduler. The problem is how to implement the optional nature of this in a race-free manner. This is obviously a pathological case, but imagine an application that does something along the following lines: int input = open ("/dev/input", O_RDONLY|O_NONBLOCK); char foo; while (1) { suspend_block(); if (read(input, &foo, 1) > 0) { (do something) suspend_unblock(); } else { suspend_unblock(); (draw bouncing cows and clouds and tractor beams briefly) } } 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 one way which indicates to the scheduler that tasks in TASK_RUNNING should be scheduled, and when the session is idle we set the flag the other way and all processes in that cgroup get shifted to TASK_INTERRUPTIBLE or something. Except that doesn't work. If the session goes idle in the middle of the app drawing a frame, we'll stop the process and the task will never call read(). So the user hits a key, we wake up, nothing shifts from TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go back to sleep. The event never gets delivered. Now let's try this in the Android world. The user hits a key and the system wakes up. The input layer takes a suspend block. The application now draws all the cows it wants to, takes its own suspend block and reads the input device. This empties the queue and the kernel-level suspend block is released. The application then processes the event before releasing the suspend block. The event has been delivered and handled. You can't express that with resource limits or QoS constraints. If you want to deal with this kind of situation then, as far as I can tell, you need either suspend blockers or something so close to them that it makes no difference. -- 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 10:30
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: > I don't entirely see how this works. In order to deal with poorly > written applications, it's necessary to (optionally, based on some > policy) ignore them when it comes to the scheduler. The problem is how > to implement the optional nature of this in a race-free manner. This is > obviously a pathological case, but imagine an application that does > something along the following lines: > > int input = open ("/dev/input", O_RDONLY|O_NONBLOCK); > char foo; > > while (1) { > suspend_block(); > if (read(input, &foo, 1) > 0) { > (do something) > suspend_unblock(); > } else { > suspend_unblock(); > (draw bouncing cows and clouds and tractor beams briefly) > } > } > > 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 > one way which indicates to the scheduler that tasks in TASK_RUNNING > should be scheduled, and when the session is idle we set the flag the > other way and all processes in that cgroup get shifted to > TASK_INTERRUPTIBLE or something. What's wrong with simply making the phone beep loudly and displaying: bouncing cows is preventing your phone from sleeping! -- 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/ |