login
Search
No, that's not how it works. It would go like this: The modem IRQ handler queues its event to the input subsystem. As it does so the input subsystem enables a suspend blocker, causing the system to stay awake after the IRQ is done. The user program enables its own suspend blocker before reading the input queue. When the queue is empty, the input subsystem releases its suspend blocker. When the user program finishes processing the event, it releases its suspend blocker. Now the system can go back to sleep. At no point does the user program have to communicate anything to the modem driver, and at no point does it have to do anything out of the ordinary except to enable and disable a suspend blocker. Alan Stern --
Exactly -- and you can use the same style of overlapping suspend blockers with other drivers than input, if the input interface is not suitable for the particular interaction. Brian --
How about instead the modem driver fails to suspend until it's done? Each driver could have a suspend_policy sysfs entry with options such as [ forced | safe ]. The default would be forced. Forced would be the current behaviour, while safe would refuse suspend until the And here the user space just tries to suspend again when it's done? It's not like you're trying to suspend all the time, so it should be Would the suspend blockers still be needed somewhere in the example above? Regards, Tony --
We actually are trying to suspend all the time -- that's our basic How often would we retry suspending? If we fail to suspend, don't we have to resume all the drivers that suspended before the one that failed? (Maybe I'm mistaken here) With the suspend block model we know the moment we're capable of suspending and then can suspend at that moment. Continually trying to suspend seems like it'd be inefficient power-wise (we're going to be doing a lot more work as we try to suspend over and over, or we're going to retry after a timeout and spend extra time not suspended). We can often spend minutes (possibly many) at a time preventing suspend when the system is doing work that would be interrupted by a full suspend. Brian --
Well based on some timer, the same way the screen blanks? Or five seconds of no audio play? So if the suspend fails, then reset whatever Sure, but I guess that should be a rare event that only happens when Maybe you a userspace suspend policy manager would do the trick if it knows when the screen is blanked and no audio has been played for five seconds etc? Regards, Tony --
This is not a rare event. For example, the matrix keypad driver blocks If user space has to initiate every suspend attempt, then you are forcing it to poll whenever a driver needs to block suspend. -- Arve Hjønnevåg --
Hmm I don't follow you. If the userspace policy daemon timer times out, the device suspends. If the device does not suspend because of a blocking driver, then the timers get reset and you try again based on some event such as when the screen blanks. Regards, Tony --
How many times we successfully suspend is irrelevant here. If the driver blocks suspend the number of suspend attempts depend on your This retry is what I call polling. You have to keep retrying until you succeed. Also, using the screen blank timeout for this polling is not a good idea. You do not want to toggle the screen off and on with with every suspend attempt. -- Arve Hjønnevåg --
I guess what I'm trying to say is that a failed suspend should be The number of retries depends on the power management policy for your device. And that is often device and use specific. So having to retry suspend should be a rare event. The userspace should mostly know when it's OK to suspend. Regards, Tony --
Actually, this is quite interesting question I'd like answer here: "Sure, but how many times per day are you suspending?" I suspect it may be in 1000s, but it would be cool to get better answer -- so that people knew what we are talking about here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
This is highly variable. 1000s would mean that you wake about once every minute which is not uncommon, but more often than what typically happens on an idle device. The nexus one has to wake up every 10 minutes to check the battery status check means your at least in the 100s, but the G1 could stay suspended for much longer than that. The original question was about a driver blocking suspend though, and if we were to just retry suspend until it succeeds in that case you could easily get to 100000s suspend attempts in a day. -- Arve Hjønnevåg --
Because every attempted suspend requires freezing userspace, suspending devices until you hit one that refuses to suspend, resuming the devies that did suspend and then unfreezing userspace. That's not an attractive option. -- Matthew Garrett | mjg59@srcf.ucam.org --
But how many times per day are you really suspending? Maybe few tens of times at most if it's based on some user activity? Or are you suspending constantly, tens of times per minute even if there's no user activity? Regards, Tony --
In this case you'd be repeatedly trying to suspend until the modem driver stopped blocking it. It's pretty much a waste. -- Matthew Garrett | mjg59@srcf.ucam.org --
But then the userspace knows you're getting data from the modem, and it can kick some inactivity timer that determines when to try to suspend next. Why would you need to constantly try to suspend in that case? Regards, Tony --
Because otherwise you're awake for longer than you need to be. -- Matthew Garrett | mjg59@srcf.ucam.org --
If your system is idle and your hardware supports off-while-idle, then that really does not matter. There's not much of a difference in power savings, we're already talking over 10 days on batteries with just off-while-idle on omaps. If your userspace keeps polling and has runaway timers, then you could suspend it's parent process to idle the system? Regards, Tony --
If your userspace is suspended, how does it process the events that generated a system wakeup? If we had a good answer to that then suspend blockers would be much less necessary. -- Matthew Garrett | mjg59@srcf.ucam.org --
Well if your hardware runs off-while-idle or even just retention-while-idle, then the basic shell works just fine waking up every few seconds or so. Then you could keep init/shell/suspend policy deamon running until it's time to suspend the whole device. To cut down runaway timers, you could already freeze the desktop/GUI/whatever earlier. Regards, Tony --
And the untrusted userspace code that's waiting for a network packet? Adding a few seconds of latency isn't an option here. -- Matthew Garrett | mjg59@srcf.ucam.org --
Hmm well hitting retention and wake you can basically do between jiffies. Hitting off mode in idle has way longer latencies, but still in few hundred milliseconds or so, not seconds. And cpuidle pretty much takes care of hitting the desired C state for you. This setup is totally working on Nokia N900 for example, it's hitting off modes in idle and running all the time, it never suspends. Regards, Tony --
The situation is this. You've frozen most of your userspace because you don't trust the applications. One of those applications has an open network socket, and policy indicates that receiving a network packet should generate a wakeup, allow the userspace application to handle the packet and then return to sleep. What mechanism do you use to do that? -- Matthew Garrett | mjg59@srcf.ucam.org --
I think the ideal way of doing this would be to have the system running and hitting some deeper idle states using cpuidle. Then fix the apps so timers don't wake up the system too often. Then everything would just run in a normal way. For the misbehaving stopped apps, maybe they could be woken to deal with the incoming network data with sysfs_notify? Regards, Tony --
Effective power management in the face of real-world applications is a How would that work? Have the kernel send a sysfs_notify on every netwrk packet and have a monitor app listen for it and unfreeze the rest of userspace if it's frozen? That sounds expensive. -- Matthew Garrett | mjg59@srcf.ucam.org --
Yeah maybe there are better ways of dealing with this. Maybe deferred timers would help some so all the apps could be allowed to run until some power management policy decides to suspend the whole device. Regards, Tony --
That's the point of the suspend blockers. -- Matthew Garrett | mjg59@srcf.ucam.org --
To me it sounds like suspending the whole system to deal with some misbehaving apps is an overkill. Sounds like kill -STOP the misbehaving apps should do the trick? Tony --
Freezer cgroups would work better, but it doesn't really change the point - if that application has an open network socket, how do you know to resume that application when a packet comes in? -- Matthew Garrett | mjg59@srcf.ucam.org --
suspend blockers can get abused also .. I had my phone in my pocket and accidentally ran "Google Talk" or something. It must have kept the screen on or kept the phone from suspending, so the battery drained completely over the course of an hour or so. Daniel --
No idea, but that still sounds a better situation to me than Yeah I guess there's nothing stopping that. Tony --
Suspend blocks deal with that problem. Nobody has yet demonstrated a workable alternative solution. -- Matthew Garrett | mjg59@srcf.ucam.org --
Well there are obviously two paths to take, I think both of them should work. The alternative to suspend blockers is: - Implement a decent kernel idle function for the hardware and use cpuidle to change the c states. The dyntick stuff should already work for most hardware. - Fix the core userspace apps to minimize timers. - Deal with broken apps whichever way you want in the userspace. - Optionally, do echo mem > /sys/power/state based on some product specific logic in the userspace. The advantage of this is that no kernel changes are needed, except for implementing the custom idle function for the hardware. And this kind of setup has been in use for about five years. And, you can keep the system running constantly if you have hardware that supports good idle modes, then you don't even need to suspend at all. The core problems I see with suspend blockers are following, please correct me if I'm wrong: - It is caching the value of echo mem > /sys/power/state and misusing it for runtime power management as the system still keeps running after trying to suspend. Instead, the kernel idle function and cpuidle should be used if the kernel keeps running. - They require patching all over the drivers and userspace. - Once the system is suspended, it does not run. And the apps don't behave in a standard way because the system does not wake to timer interrupts. I agree that we need to be able to echo mem > /sys/power/state in an atomic way. So if there are problems with that, those issues should be fixed. Cheers, Tony --
If we could do this then there would be no real need for suspend blockers. -- Matthew Garrett | mjg59@srcf.ucam.org --
OK, I guess I don't understand all the details, need some kind of common example I guess. So for example, if I leave ping running in a a terminal, do you have some way of preventing that from eating the battery? In my scenario that program would keep on running until the battery runs out, or something stops the program. But the system keeps hitting retention mode in the idle loop. How do you deal with programs like that? Do you just suspend the whole system anyways at some point, or do you have some other trick? Regards, Tony --
It depends on policy. If all network packets generate wakeup events then no, that will carry on eating battery. If ICMP doesn't generate a wakeup If nothing's holding any suspend blocks then the system will enter suspend. If the packet generates a wakeup then the kernel would block suspend until userspace has had the opportunity to do so. Once userspace has handled the packet then it could release the block and the system will immediately transition back into suspend. Here's a different example. A process is waiting for a keypress, but because it's badly written it's also drawing to the screen at 60 frames per second and preventing the system from every going to idle. How do you quiesce the system while still ensuring that the keypress will be delivered to the application? -- Matthew Garrett | mjg59@srcf.ucam.org --
I guess it depends. If it's a game and I'm waiting to hit the fire button, then I don't want the system to suspend! It's starting to sound like you're really using suspend blocks to "certify" that the app is safe to keep running. Maybe it could be done with some kind of process flag instead that would tell "this process is safe to keep running from timer point of view" and if that flag is not set, then assume it's OK to stop the process at any point? Regards, Tony --
We don't suspend while the screen is on. If the user pressed the power button to turn the screen off, then I would not want the game to -- Arve Hjønnevåg --
How do you know to wake the process up in response to the keypress? -- Matthew Garrett | mjg59@srcf.ucam.org --
Does it matter for processes that are not "certified"? Maybe you could assume that you can keep it stopped until the screen is on again, or some other policy. Tony --
Yes, it matters. You don't necessarily know whether to turn the screen on until the app has had an opportunity to process the event. This is exactly the kind of use case that suspend blocks are intended to allow, so alternatives that don't permit that kind of use case aren't really adequate alternatives. -- Matthew Garrett | mjg59@srcf.ucam.org --
Hmm, I'm thinking there would not be any need to turn the screen on for the broken apps until some other event such as a tap on the screen triggers the need to turn the screen on. If it's a critical app, then it should be fixed so it's safe to keep running. And yeah, I guess you could cgroups to categorize "timer certified" and "broken" apps. Regards, Tony --
This is a perfectly valid model, but it's not one that matches Android. -- Matthew Garrett | mjg59@srcf.ucam.org --
To me it's somewhat of a negative for suspend blockers. Since to solve the problem you give above you would have to use a suspend blocker in an asynchronous way (locked in an interrupt, released in a thread too) assuming I understand your example. I've had my share of semaphore nightmares, and I'm not too excited to see a protection scheme (i.e. a lock) which allows asynchronous usage like suspend blockers. Daniel --
Why do you think this? The example in the documentation describe how we handle key events. -- Arve Hjønnevåg --
+- The Keypad driver gets an interrupt. It then calls suspend_block on the + keypad-scan suspend_blocker and starts scanning the keypad matrix. +- The keypad-scan code detects a key change and reports it to the input-event + driver. +- The input-event driver sees the key change, enqueues an event, and calls + suspend_block on the input-event-queue suspend_blocker. +- The keypad-scan code detects that no keys are held and calls suspend_unblock + on the keypad-scan suspend_blocker. +- The user-space input-event thread returns from select/poll, calls + suspend_block on the process-input-events suspend_blocker and then calls read + on the input-event device. +- The input-event driver dequeues the key-event and, since the queue is now + empty, it calls suspend_unblock on the input-event-queue suspend_blocker. +- The user-space input-event thread returns from read. If it determines that + the key should leave the screen off, it calls suspend_unblock on the + process_input_events suspend_blocker and then calls select or poll. The + system will automatically suspend again, since now no suspend blockers are + active. This? Isn't this asynchronous on the input-event-queue since it's taken in the interrupt , and release in the userspace thread? Daniel --
Check the input patch for an example of this. -- Matthew Garrett | mjg59@srcf.ucam.org --
Makes me wish g1 was omap based... it looks like you have superior hw. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
G1 will happily do 10 days idle (radio on) under typical network conditions (roughly 4-5mA draw at the battery average in paging mode) if you have data disabled and there's no reason for it to wake up, process events, chat on the data network etc. It'll go 25-30 days in "airplane mode" (radio off) provided there are not excessive wakeups. If you happen to be running a perfect userspace where every thread in every process is blocked on something, it'll hit the exact same power state out of idle. If you have a less optimal userspace or random third party nonoptimal apps, this becomes much harder, of course. Which is why we do the wakelock thing. OMAP does have a lot of nice auto-clock-down features compared to some other SoCs, sometimes simplifying other parts of power management. Brian --
If the idle thread was doing the suspending then the inactivity timer by it's self could block suspend. As long as the idle thread was setup to check for timers. I'm sure that _isn't_ the point your trying to make. It just makes gobs more sense to me that the idle thread does the suspending .. Your idle, so depending on how long your idle then you suspend. Daniel --
The alternative logic I'm suggesting is get the GUI into idle mode as soon as possible, then limp along with off-while-idle or retention-while-idle until some timer expires, then suspend the whole device. Tony --
Could you elaborate on "off-while-idle" and "retention-while-idle" ? I'm not sure I follow what you mean. Daniel --
Oh some SoC devices like omap hit retention or off modes in the idle loop. That brings down the idle consumption of a running system to minimal levels. It's basically the same as suspending the device in every idle loop. The system wakes up every few seconds or so, but that already provides battery life of over ten days or so on an idle system. Of course the wakeup latencies are in milliseconds then. Regards, Tony --
MSM doesn't have those power states unfortunately .. Your kind of suggesting what I was suggesting in that we should suspend in idle. Your hardware can do it easier tho since your have power states that are equal to suspend. Daniel --
If your wakeup latencies are sufficiently low and you have fine-grained enough control over your hardware then suspend in idle is a reasonable thing to do - but if you have a userspace app that's spinning then that doesn't solve the issue. -- Matthew Garrett | mjg59@srcf.ucam.org --
If there's a userspace app spinning then you don't go idle (or that's my assumption anyway). You mean like repeatedly blocking and unblocking right? Daniel --
Right, that's the problem. idle-based suspend works fine if your applications let the system go idle, but if your applications are anything other than absolutely perfect in this respect then you consume significant power even if the device is sitting unused in someone's pocket. -- Matthew Garrett | mjg59@srcf.ucam.org --
True .. I'd wonder how an OMAP based devices deal with that issue, since they would have that exact problem. According to what Tony is telling us. Actually a bogus userspace can do a lot more than just consume power you could hang the system too. Daniel --
There's nothing being done on omaps specifically, up to the device user space to deal with that. From the kernel point of view the omaps just run, and if idle enough, the device starts hitting the retention and off modes in idle. But the system keeps on running all the time, no need to suspend really. I don't think there's a generic solution to the misbehaving apps. I know a lot of work has been done over past five years or so to minimize the timer usage in various apps. But if I installed some app that keeps the system busy, it would drain the battery. I guess some apps could be just stopped when the screen blanks unless somehow certified for the timer usage or something similar.. Regards, Tony --
You might be able to implement suspend-while-idle with cpuidle and a custom idle function on MSM. That is if MSM supports waking to a timer event and some device interrupts. However, if it only wakes to pressing some power button, then you will get missed timers and the system won't behave in a normal way. Maybe you could still kill -STOP the misbehaving apps, then keep the idle system running until some timer expires, then when no activity, echo mem > /sys/power/state? Regards, Tony --
lets not go off in the weeds for the wrong things now. The answer to the retry is at most one time. The first time would be blocked, then the suspend enable would need to re-enabled under user mode control that would, buy that time, know it has to ack to the modem to stop rejecting the suspend attempt. duh. --mgross --
This is incorrect in the general case. User-space has no way of knowing which driver blocked suspend or when it will stop blocking suspend. -- Arve Hjønnevåg --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth< |