Re: [PATCH 00/20] world-writable files in sysfs and debugfs
Thanks, I've applied the x86 platform driver ones. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote: Sure, but my point was, some non-trivial (still kind of natural for a smartphone) activities with the device will prevent it from suspending for quite some time. Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. Yep, I know about the early suspend type of thing; yet it's excess, not mainlined and lacks granularity. Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:05:57PM +0100, Alan Cox wrote: On Sun, 6 Jun 2010 12:46:01 +0200 Florian Mickler flor...@mickler.org wrote: That is not true. While the kernel is not suspended it does runtime pm. On several of our platforms runtime PM already includes suspend so a suspend wakelock does interfere with existing power managemet at that level (not to mention the maintenance mess it causes). No, it doesn't. Android on omap will enter the mpu/core off state from the idle loop even if a suspend block is held. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. Yeah, that might also be the case, But then again, what's the use of suspend blockers in this situation? The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. Right, and then you start taking suspend blockers in kernel here and there which eventually interferes with runtime PM. Suspend blocks prevent system suspend, not any per-device suspend. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? Yes. Suspend blocks are orthogonal to runtime PM. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote: The other vendors appear to be managing nicely without magic blockers. I conjecture therefore there are other solutions. Actually, no. A badly behaved application will kill the N900's battery life. Nobody else has managed nicely - they've just made life harder for application developers and users, which may have something to do with the relative levels of market adoption of Maemo and Android. I'm not aware of any form of resource management framework in MeeGo either, so as far as I know it'll have exactly the same problem. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote: On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote: At the point where you're rewriting the application you can just make it adhere to our current behavioural standards anyway. Thank you for confirming that the so-called feature is just there to make apps work in some area that are crappy anyways - and God knows in which other areas they are crappy too. Kind of like memory protection, really. Or preemptive multitasking. Or many things that the kernel does to prevent badly written applications from interfering with other applications or the user's experience. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 01:21:38PM +0100, Alan Cox wrote: So I put my phone down The UI manager gets told the phone is 'down' Ten seconds later it is still down - wakeup event that should be delivered to untrusted app arrives here At this point you may mark the downtrodden group as ignored between the untrusted app receiving the event and the untrusted app marking itself as important. To avoid this you need the UI manager to receive every wakeup event in order to change its scheduling decisions. If I push the button we get an IRQ We come out of power save The app gets poked (The cgroup has to have some awareness of suspend/resume so that it can allow the untrusted apps to be scheduled again) The app may be unimportant but the IRQ means we have a new timeout of some form to run down to idle The timeout-based nature means that if the application doesn't get scheduled for some reason (say there's heavy swap pressure - not likely in the embedded world, but an issue on laptop-type devices) the event may not be handled before you get back to sleep. I accept that this isn't likely to be a problem in the real world, but it does make this mechanism less deterministic than a suspend block based one. If you are absolutely utterly paranoid about it you need the button driver to mark the task it wakes back as important rather than rely on time for response like everyone else. That specific bit is uggglly but worst case its just a google private patch to a few drivers. I understand why Android wants it. The narrower the gap between 'we are doing nothing, sit in lowest CPU on state' and 'we are off' the better the battery life and the more hittable the condition. Not just the button driver. Every driver that generates wakeupa. This gets difficult when it comes to the network layer, for instance, when the network driver has very little idea how the packet it just received will be routed. Apart from that optional paranoia case my kernel now contains some trivial changes of generic value that have nothing to do with suspend blocking. Android has suspend blocking by choosing to use the generic features in its own specific way and we need almost no code writing ? The problem is that you still have a race, and fixing that race requires every event that could generate a wakeup to be proxied out to the policy manager as well. That's a moderate additional overhead. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 05:49:36PM -0700, Mike Chan wrote: Even if we used the proposed QoS replacement, are there suggestions on how to keep the cpu idle for longer than 2 seconds in Linux without using suspend? I believe that the Maximum idle time on 32-bit is 2 seconds issue is solved in recent kernels. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 02:54:20PM +0100, Alan Cox wrote: I am not convinced at this point. If the app gets put into the important group by the driver then you don't need to poke a policy manager. Ok, I think I've misunderstood you. You're actually saying that only applications that are trusted to behave well are allowed to receive wakeup events? Yes, that makes implementation significantly easier. If that maps reasonably well onto the existing Android application space, it may even be an acceptable compromise. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote: The following cannot occur on my laptop for simple idling Alarm Suspend because the Alarm resets the suspend timer when it is delivered. Userspace is about to write to /sys/power/state when it gets scheduled. Alarm delivery occurs at that instant. Kernel has no idea that it's about to go to sleep, so the driver handles things appropriately and clears the hardware state. Userspace gets scheduled, writes and the system suspends. The problem is that having userspace decidie to initiate a suspend and then actually initiate a suspend isn't an atomic operation. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote: I have seen very good proposals for saner solutions. Is that progress? The proposals so far involve either redefining the problem space or being inherently racey. It may be that we can redefine the problem space in such a way that everyone's happy, but it's not possible to do so by fiat. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 07:29:27AM -0700, Brian Swetland wrote: I need to think more about the cgroups approach, but I'm pretty sure it still suffers from wakeup race situations, and due to the complexity of userspace (at least ours), I suspect it would risk livelock/deadlock/priority-inversion style issues due to interaction between different processes in different groups. I think the cgroups approach works if you assume that applications that consume wakeup events can be trusted to otherwise be good citizens. Everything that has no direct interest in wakeup events (except the generic Android userspace) can be frozen, and you can use the scheduler to make everything else Just Work. That's a rather big if, but you've got a better idea of the state of the Android app base than I do. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: 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! Well, primarily that it's possible to design an implementation where it *doesn't* prevent your phone froms sleeping, but also because a given application may justifiably be preventing your phone from sleeping for a short while. What threshold do you use to determine the difference? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: 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. Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. Stop thinking about suspend as a special mechanism. It's not - except for s2disk, which is an entirely different beast. On PCs, suspend has more in common with s2disk than it does C states. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? Because you may then block them in such a way that they never handle an event that should wake them. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: You still need the in-kernel suspend blockers if you want to guarantee that you can't lose wakeup events. But yes, if you're not concerned handling badly behaved applications then I believe that you can lose opportunistic suspend and just use the scheduler. No, we do not. We need correctly implemented drivers and a safe switchover from normal event delivery to wakeup based. What is a Correctly implemented driver in this case? One that receives a wakeup event and then prevents suspend being entered until userspace has acknowledged that event? Because that's what an in-kernel suspend blocker is. My question was about explicit suspend states, not implicitly handling an identical state based on scheduler constraints. Suspend-as-a-C-state isn't usable on x86 - you have to explicitly trigger it based on some And why not ? Just because suspend is not implemented as an ACPI C-state ? Nonsense, if we want to push the system into suspend from the idle state we can do that. It's just not implemented and we've never tried to do it as it requires a non trivial amount of work, but I have done it on an ARM two years ago as a prove of concept and it works like a charm. 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. policy. And if you want to be able to do that without risking the loss of wakeup events then you need in-kernel suspend blockers. Crap. Stop beating on those lost wakeup events. If we lose them then the drivers are broken and do not handle the switch over correctly. Or the suspend mechanism is broken as it does not evaluate the system state correctly. Blockers are just papering over that w/o tackling the real problem. Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the driver to indicate whether the wakeup event has been handled. That's what they're there for. The in-kernel ones don't paper over anything. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote: Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. Nothing gets scheduled in a deep idle state either - its idle. We leave the idle state to schedule anything. Certainly, if you can force the system to be idle then you don't need opportunistic suspend. But you haven't shown how to do that without it being racey. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote: Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution. Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that: 1) Force the system to be idle. Doing this race-free is difficult. 2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: How (and why) does the WoL (which may be *any* packet, not just a magic one) turn the screen back on? Why would you care about the screen for a network event? Because the application that needs to handle the network packet is currently blocked trying to draw something to the screen. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: we still need to be able to enter suspend while the system isn't idle. _WHY_!? Because if I'm running a kernel build in a tmpfs and I hit the sleep key, I need to go to sleep. Blocking processes on driver access isn't sufficient. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: Why would you care about the screen for a network event? Because the application that needs to handle the network packet is currently blocked trying to draw something to the screen. Then that's an application bug right there, isn't it? If should have listened to the window server telling its clients it was going to go away. Drawing after you get that is your own damn fault ;-) How long do you wait for applications to respond that they've stopped drawing? What if the application is heavily in swap at the time? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. Suspend blockers are the mechanism for the driver to indicate whether the wakeup event has been handled. That's what they're there for. The in-kernel ones don't paper over anything. Semantically the in kernel blockers and the in kernel expression of device driven constraints are the same thing except that instead of yes/no you replace the boolean with information. In some cases, not all. It may be a latency constraint (in which case pm_qos is an appropriate mechanism), but instead it may be something like A key was pressed but never read or A network packet was received but not delivered. These don't fit into the pm_qos model, but it's state that you have to track. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote: Then that's an application bug right there, isn't it? If should have listened to the window server telling its clients it was going to go away. Drawing after you get that is your own damn fault ;-) How long do you wait for applications to respond that they've stopped drawing? What if the application is heavily in swap at the time? Since we're talking about a purely idle driven power saving, we wait until the cpu is idle. If that's what you're aiming for then you don't need to block applications on hardware access because they should all already have idled themselves. Note that it doesn't need to broadcast this, it could opt to reply with that message on the first drawing attempt after it goes away and block on the second. That's more interesting, but you're changing semantics quite heavily at this point. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote: How so, event happens on hardware level, IRQ gets raised, CPU wakes up, handler gets run, handler generates a task wakeup, runqueue isn't empty, we run stuff. If you're using idle-based suspend without any forced idling or blocking of applications then you don't lose wakeups. People keep conflating separate issues. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote: Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system? If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers. That's entirely orthogonal to Android's runtime power management. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: If that's what you're aiming for then you don't need to block applications on hardware access because they should all already have idled themselves. Correct, a well behaved app would have. I thought we all agreed that well behaved apps weren't the problem? Ok. So the existing badly-behaved application ignores your request and then gets blocked. And now it no longer responds to wakeup events. So you penalise well-behaved applications without providing any benefits to badly-behaved ones. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
This is still racy. Going back to this:
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 {
* SUSPEND OCCURS HERE *
Fine but then the packet will arrive and we will wake back up process the
packet and wake the task. See suspend is just like a deep sleep. If we
went to sleep there and the packet arrival doesn't rewake the box the
driver was buggy.
Yes, there's no problem so far. The question is how you guarantee that
the application has had the opportunity to handle the packet.
reaches the end of its timeslice. At this point the application has not
had an opportunity to indicate in any way whether or not the packet has
altered its constraints in any way. What stops us from immediately
suspending again?
If my app level constraint before the packet is 'don't suspend' then my
constraint on receipt is 'don't suspend' so I won't suspend. If my
constraint is then lowered and I suspend I will suspend *after* the
lowering.
If the app level constraint before the packet was don't suspend, we
wouldn't have suspended. Here's a description of the desired behaviour
of the application as you requested:
The application is a network monitoring app that renders server state
via animated bouncing cows. The desired behaviour is that the
application will cease to be scheduled if the session becomes idle
(where idle is defined as the system having received no user input for
30 seconds) but that push notifications from the server still be
received in order to allow the application to present the user with
critical alerts.
Under Android:
User puts down phone. 30 seconds later the screen turns off and releases
the last user-level suspend block. The phone enters suspend and the
application is suspended. A network packet is received, causing the
network driver to take a suspend block. The application finishes the
frame it was drawing, takes its own suspend block and reads the network
packet. In doing so the network driver releases its suspend block, but
since userspace is holding one the phone stays awake. The application
then handles the event as necessary, releases its suspend block and the
phone goes to sleep again.
I don't see how this behaviour can be emulated in your model.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote: If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers. That's entirely orthogonal to Android's runtime power management. The simple fact of life is, on PC style hardware suspend is mostly about missing events. I really _really_ want to miss mouse movement of my bluetooth mouse when the gear is stowed in my backpack. That's fine - those shouldn't be configured as wakeup events. Its perfectly OK to miss events on _forced_ suspend. No, it's not. Forced suspend may be in response to hitting a key, but it may also be in response to a 30 minute timeout expiring. 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. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote: I'd prefer we avoided mixing them up. Everyone seems fairly happy with the current operator ordered suspend behaviour I believe ? No. The current mechanism can lose wakeup events. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:05:39PM +0200, Thomas Gleixner wrote: You're just not getting it. If user space has consumed the event is not relevant at all. What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters. And how do you know that? We can't rely on the process scheduler. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: If that's what you're aiming for then you don't need to block applications on hardware access because they should all already have idled themselves. Correct, a well behaved app would have. I thought we all agreed that well behaved apps weren't the problem? Ok. So the existing badly-behaved application ignores your request and then gets blocked. And now it no longer responds to wakeup events. It will, when it gets unblocked from whatever thing it got stuck on. 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? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:12:15PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: How long do you wait for applications to respond that they've stopped drawing? What if the application is heavily in swap at the time? Very realistic scenario on a mobile phone. If the aim is to produce a solution that isn't special-cased to specific devices, thinking about how long an application may take to respond is entirely relevant. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett 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. Right, it does not as of today. So we cannot use that on x86 hardware. Fine. That does not prevent us to implement it for architectures which can do it. And if x86 comes to the point where it can handle it as well we're going to use it. Where is the problem ? If x86 cannot guarantee the wakeup sources it's not going to be used for such devices. The kernel just does not provide the service for it, so what ? We were talking about PCs. Suspend-as-c-state is already implemented for OMAP. So the only thing you are imposing to app writers is to use an interface which solves nothing and does not save you any power at all. It's already been demonstrated that the Android approach saves power. Runnable tasks and QoS guarantees are the indicators whether you can go to opportunistic suspend or not. Everything else is just window dressing. As I keep saying, this is all much less interesting if you don't care about handling suboptimal applications. If you do care about them then the Android approach works. Nobody has demonstrated a scheduler-based one that does. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote: 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? In order to cancel the suspend we need to keep track of whether userspace has consumed the event and reacted appropriately. Since we can't do this with the process scheduler, we end up with something that looks like suspend blockers. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote: 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? So why bother blocking? Just kill the app and tell the user. If you want to support suboptimal apps then blocking isn't sufficient. If you don't want to then blocking isn't necessary. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote: The application is a network monitoring app that renders server state via animated bouncing cows. The desired behaviour is that the application will cease to be scheduled if the session becomes idle (where idle is defined as the system having received no user input for 30 seconds) but that push notifications from the server still be received in order to allow the application to present the user with critical alerts. This is a bit confusing - does the screen come back on for such events, what constraints is the server operating under ? How does your code look - it's hard to imagine the examples you've given as being workable given they would block on network packet wait when a critical event occurs. Are you using poll or threads or what ? It's code that's broadly identical to what I posted. The screen will come on if the event is critical, won't otherwise. Under Android: User puts down phone. 30 seconds later the screen turns off and releases the last user-level suspend block. The phone enters suspend and the application is suspended. A network packet is received, causing the network driver to take a suspend block. The application finishes the frame it was drawing, takes its own suspend block and reads the network packet. In doing so the network driver releases its suspend block, but since userspace is holding one the phone stays awake. The application then handles the event as necessary, releases its suspend block and the phone goes to sleep again. I don't see how this behaviour can be emulated in your model. User puts down phone. 30 seconds later the X server decides to turn the screen off and closes the device. This probalby releases the constraint held via the display driver not to suspend. Any further draw requests will block. System looks at the other tasks and sees they are idle and can sink to a low power state. Cows is either blocked on a packet receive or could even be blocked on writing to the display (or both if its a realistic example and using poll) Even if it's using poll, it could block purely on the display if X turns the screen off between poll() waking and the write being made. The kernel looks at the constraints it has - must not sink to a state below which network receive of packets fails - must not sink below a state where whatever is needed for the critical alert code etc to do its stuff - must not sink to a state which takes more than [constraint] seconds to get back out of It picks 'opportunistic suspend' It goes to sleep A packet arrives It wakes the hardware We are busy, we do not wish to suspend It processes the packet It wakes the user app It starts processing the packet If it's blocked on the write then it only starts processing the packet again if the screen wakes up. You need to power up every piece of hardware that an application's blocked on, just in case they need to complete that read or write in order to get back to the event loop where they have the opportunity to read the network packet. So, yes, I think this can work in that case. But it doesn't work in others - you won't idle applications that aren't accessing hardware drivers. As an aside, I think this is a good idea in any case since a fringe benefit is the removal of the requirement to use the process freezer in suspend to RAM... Stop transitioning Run-Forced Suspend. If you've got stuff stuck running then deal with it by constraining it to go idle or by blowing it out of the water. PM will then do the rest. The problem is determining how to constrain it to go idle, where idle is defined as Doesn't wake up until a wakeup event is received. It's acceptable for something to use as much CPU as it wants when the user is actively interacting with the device, but in most cases processes shouldn't be permitted to use any CPU when the session is idle. The question is how to implement something that allows a CPU-guzzling application to be idled without impairing its ability to process wakeup events. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote: So I guess if you are driving this rom user space (which I take it you are given you talk about housekeeping) foreach app we need to suspend kick app to suspend (signal) (policy) kick harder if needed (SIGSTOP/bitch/shall I kill it dialogue) This would need to be atomic, but in any case: 1) Policy decision is made 2) Wakeup event is received by task 3) Task gets stopped between receiving the event and handing it off to policy agent At which point you suspend when you should have remained awake. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote: On Thu, 27 May 2010 20:29:26 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: But wakeup events won't be delivered to STOPped processes, and there's Try the following cat pipe kill -STOP catpid echo wombats are cool pipe kill -CONT catpid it will echo wombats are cool The event was not lost. Not lost, but not delivered. So you need your policy agent to send SIGCONT when you receive any wakeup event, which either means proxying all your network traffic through your policy agent or having some mechanism for alerting the policy agent whenever you leave the deep idle state. also the race of an application being in the middle of handling a wakeup event when you send it the signal. sigmask() Doesn't help - I may be hit by the signal between the poll() unblocking and me having the opportunity to call sigmask(). -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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. Consider the case where the read() is non-blocking. Which I consider in the same range as the application which does: while (1); Not at all. Depending on what it reads, it may follow some other path where it sleeps. But, as I keep saying, if you don't want to support that kind of code then all of this is massively easier. What sets that flag, and how does it interact with an application that never makes a blocking system call? QoS(NONE) would be default policy for untrusted apps in the same way as you'd refuse the usage of supsend blockers for untrusted apps. while (1); is definitely not an application which should be granted trusted rights, right ? No, but if that while (1) is draw_cows() then the user may want this to run while their session is active and stop running while their session is idle. So you only want it to be QoS(NONE) in the idle session case. How do you change that state? The numbers were earlier in the thread. Numbers, yes. But I really give a sh*t about numbers w/o a detailed explanation of the scenario which created those numbers. And if the numbers boil down to: we handle the untrusted app which does while (1); then they are absolutely useless. The tested case was a stock Android install with opportunistic suspend enabled and one that just used runtime idle. The lowest power state entered was the same on both. Yes, and I'd agree with this if anyone seemed to have any idea how to do it right. But despite all the heat and noise in this thread, all we've got is an expression that it should be handled by the scheduler (a viewpoint I agree with) without any explanation of how to switch policies in such a way that applications idle without losing wakeup events. Why in the world should they lose wakeup events ? If an app goes idle, it goes idle because it is waiting for an event. There is no other sane reason except for those apps which are untrusted and force idled. And for those you agreed already the suspend blockers don't solve anything as they are either not implemented or the app is not trusted to use them. So we are back to round one of the whole discussion: Is it worth to create an utter mess in the kernel just to handle a subset of crappy coded applications ? And the answer stays the same: No, not at all. You need suspend blockers to avoid losing wakeups in the explicit suspend case even if you don't want to implement opportunistic suspend. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:03:14PM +0100, Alan Cox wrote: On Thu, 27 May 2010 18:59:20 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: Ok. So the existing badly-behaved application ignores your request and then gets blocked. And now it no longer responds to wakeup events. So you penalise well-behaved applications without providing any benefits to badly-behaved ones. I don't see how you put the first two sentences together and get the final one. When you beat up badly behaved apps that doesn't penalise well behaved ones. If you're going to block an app on drawing then you either need to reenable drawing on wakeup or you need to have an interface for alerting the app to the fact that drawing is about to block and it should get back to its event loop. The first is suboptimal, the second penalises well behaved apps. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote: Not lost, but not delivered. So you need your policy agent to send it will be delivered next time the process wakes. It's not lost. SIGCONT when you receive any wakeup event, which either means proxying all your network traffic through your policy agent or having some mechanism for alerting the policy agent whenever you leave the deep idle state. You didn't mention that requirement last time. I thought it was pretty obvious that wakeup events had to actually be delivered to the applications that are listening for them. also the race of an application being in the middle of handling a wakeup event when you send it the signal. sigmask() Doesn't help - I may be hit by the signal between the poll() unblocking and me having the opportunity to call sigmask(). ppoll(). This is all existing solved stuff. Isn't that the inverse of what we want? The application should default to being SIGSTOPpable except in the case of it being in the process of having a specific event delivered. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote: Would it help to divide the application into two processes, one of which receives events and the other does the drawing? At the point where you're rewriting the application you can just make it adhere to our current behavioural standards anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote: On Thu, 27 May 2010 18:25:10 +0100 Matthew Garrett mj...@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 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. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote: On Thu, 27 May 2010 22:36:35 +0100 Matthew Garrett mj...@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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: 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. We've already established that ACPI systems require us to force running tasks into suspend. How do we avoid the race in that situation? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:32:47PM +0100, Alan Cox wrote: The kernel performs no explicit notification to userspace. With legacy For a PC ACPI using type device /proc/acpi/events which wakes acpid which wakes gnome-power-manager which wakes half the universe No, there's no explicit /proc/acpi/event notification on resume. Do we need a better more generic version of the events files - maybe but thats a rather different kettle of fish to suspend blockers. It's a requirement for any reasonable alternative approach. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote: On Thu, 27 May 2010 23:09:49 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: 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. We've already established that ACPI systems require us to force running tasks into suspend. How do we avoid the race in that situation? Android phones do not have ACPI. Embedded platforms do not have ACPI. MID x86 devices do not have ACPI. It doesn't matter. Right now there's a race condition in terms of wakeup events on ACPI systems. What's your proposal for fixing that? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote: IMO the real fix would be on that particular poll(), changing the timeout e.g. based on cpufreq notifications or even relying completely on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a crude example trying to show that the real issue lies on the application rather than on kernel. We know that this problem is mostly uninteresting if your userland is well written. The sad truth is that it's impossible to trust that your userland is well written, and broadly impossible to communicate to users that the reason that their battery life is miserable is because of the applications and not because of the platform. If you don't believe that that's a worthwhile use case to deal with then suspend blockers buy you pretty much nothing. But if you do, then nobody's yet demonstrated another workable way for this to be handled. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 14:16]: What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. Can you describe where do you see the race now? 1) Trusted app decides to suspend 2) Network packet that would otherwise wake the system is received 3) Trusted app sends SIGSTOP to untrusted userspace 4) Network packet sits waiting for stopped userspace to process it Unless the trusted userspace gets woken up on every event that would potentially cause a wakeup, you're racy. And the alternative involves an extra userspace wakeup for every network packet - which is expensive. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Ok. So we stick the untrusted bits of userspace on the critical timer list. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:29]: And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. Your system should wake up to an interrupt in that case. Then you have the trusted apps running that can decide if the untrusted apps should be continued or not. What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
