login
Search
This is where you are wrong. Maybe not wrong in principle, but wrong in practice -- the kernel's present suspend-to-RAM (or just "suspend") implementation is _very_ different from C-states (or just "idle"). The primary difference is that the kernel can be forced into suspend even when the system isn't idle. In particular, it may be in the middle of processing a potential wakeup event -- and the current design gives the PM core no way to know if that is so. This is a weakness that in-kernel suspend blockers fix. With C-states this can't happen. If the CPU goes into a deeper C-state then ipso facto it isn't busy processing anything, much less a wakeup event. Now maybe this difference is a bad thing, and the whole PM suspend/hibernate infrastructure should be rewritten. But the fact, remains, that's how it works now. And it can't be changed easily or quickly. Alan Stern --
Holy bouncing cow. I damned good know that the current implementation is not doing that and that suspend is implemented in a totally different way. That does not mean that this is written in stone. We 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 And that's the whole point of doing the opportunistic suspend with the So what you are saying is that we better paper over the shortcomings of our current implementation with do_not_suspend() code sprinkled all over the place instead of sitting down and making suspend from idle work. It's more or less trivial depending on the platform, but not rocket science. Thanks, tglx --
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 | mjg59@srcf.ucam.org --
_WHY_!? We've been trying to tell you you don't need that. --
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 | mjg59@srcf.ucam.org --
But that's a whole different issue. I agree that a forced suspend for things like that make sense, just not for power managing a running system. PC style hardware like that doesn't wake up from suspend for funny things like a keypress either (good thing too). Anyway all that already works (more or less), so I don't see the problem. --
The whole idea behind the patchset is not to power manage a _running_ system. It is based on the observation that for a good deal of time one doesn't need the system to be running at all, which is quite pragmatic to me. Given that, the point is to figure out when the system doesn't need to run and effectively shut it down at that point (memory is refreshed in that state so that the system can go back to the working state relatively quickly). From there, the system can only be woken up by specific events (like pressing a power button). However, it would be wasteful to shut it down knowing that the condition used to make the decision to shut it down didn't hold any more. The current mainline relies on the user to make that decision (and write something to /sys/power/state), but in principle I don't see why it cannot be made by software (either the kernel or the user space, or both in combination). The question is how to "teach" the software to make that decision in a way that's acceptable to the user and the Arve's approach is an attempt to give an answer to it. Of course, you may not like it, but the truth is it works in practice reasonably well. That may not be an argument for merging it, but then we should at least tell the Android people what's fundamentally wrong with it and how to do it in a different way so that their own requirements are met. As long as we don't do that, we're rejecting it just because we don't like it. Yes, Alan Cox said why he thought the approach was fundamentally wrong from the technical standpoint and I appreciate that. I don't think, though, that we can give Google a serious advice how to achieve their goal (which is battery life comparable to what they get with suspend blockers) in any different way. The approach with user space power manager suggested by Dmitry and Alan Stern may work, but it still assumes some kind of suspend blockers to be present in the kernel. If we reject that too, I wonder what approach Google is supposed to ...
I'm getting less convinced it needs suspend blockers at all for this case, assuming that you are willing to have a policy that is based on - assuming apps play nicely - having the information to user space you need (who woke us, who blocked us, events) - dealing with offenders primarily from user space using that information I'm fairly happy about the following so far - we should have a common interface for seeing some pm events (like duh ?) but it does need careful thought so the watcher doesn't change the behaviour and break it. (Message "We are suspending", gosh someone is running to receive the message, resume being the obvious case) - Suspend is (for many platforms) just a cotinuation down the power chain. Demonstrated and implemented on ARM. Very much the direction of S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and made to work, and by reading the Moorestown PR. - Given a non forced (that is 'idle down') transition to a suspend level we can implement a 'suspend as idle' on many embedded platforms in a manner which is not racy at kernel level. Apparently implemented already on ARM - Given a non forced transition to such a suspend level and the reporting of certain events we can do a full user space managed graphical UI type environment policy in a race free fashion - With notification of who caused a resume and maybe a bit of other general stat gathering it is possible to identify and handle abuses of power resource. Proved by the fact we can do this with powertop but more elegance in the interfaces would be nice. I am not sure if a pm event is what is needed for this or a sum 'hardware triggered wake up' event. I accept that current ACPI based laptops probably couldn't make use of such a feature but I don't think this is important at the moment. A resource constraint model might help further in the ACPI case. It's useful for other stuff but it might well be a distraction and implementation detail in ...
Just to confirm, yes, it is already implemeted on ARM, and in mainline for the TI OMAP3 (ARM Cortex-A8) and in commercial products (Nokia N900, Moto Droid, Palm Pre, Archos, etc.) For the OMAP the deepest C-state is actually a fully powered-down ARM core. While the Droid uses 'suspend as idle' in addition to opportunistic suspend, the N900 *never* suspends in the traditional sense, it is entirely idle based. Kevin --
OK, I added Arve and Brian to the CC list. Thanks, Rafael --
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? On a thread somewhere I had real world power numbers on a Motorola Droid idling (screen off) with and without suspend blockers. --
What exactly is stopping it from being idle? --
I believe that the "Maximum idle time on 32-bit is 2 seconds" issue is solved in recent kernels. -- Matthew Garrett | mjg59@srcf.ucam.org --
On Thu, 27 May 2010 18:40:19 +0100 Suspend as an idle state Suspend as a 'hand of God' choice. One is a performance optimisation the other is an operator executive decision. 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 | mjg59@srcf.ucam.org --
And the proposed solution (suspend blockers) does nothing to solve the loss of wakeup events during forced suspend. Kevin --
As long as the operator agrees to lose wakeup events occasionally, which is the case at least 99% of the time, there's nothing wrong with that IMO. Rafael --
That's the difference between opportunistic and enforced suspend. On enforced suspend the QoS guarantee is forced to NONE for everything and you go down no matter what. When you decide to push the wakeup button the system restores. Thanks, tglx --
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. Emptying your input queue is just the wrong indicator. And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway. And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed. The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise. Thanks, tglx --
And how do you know that? We can't rely on the process scheduler. -- Matthew Garrett | mjg59@srcf.ucam.org --
On Thu, 27 May 2010 20:05:39 +0200 (CEST) Thomas, do you really have a problem with the actual concept? Or do you just don't like the way it is done? IMO, the whole concept is defining 2 modes of operation: 1. user interacts with the device (at least one suspend block active) 2. user doesn't interact with the device (zero suspend block active) In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now). In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend) And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user. (Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?) We can only enter mode 2, if _nothing_ (claims) to interact with the user. To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call? Attributes of the idle states could be smth like this: c3 cost-to-transition-to-this-state: X powersavings-per-time: Y expected time we stay in this state: relative short, there is a timer sheduled suspend-blockers: ignored suspend cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save powersavings-per-time: Y expected time we stay in this state: long, independent of sheduled timers suspend-blockers: must not be activated Now all transitions and opportunistic suspend could be handled by the same algorithms. Would this work? Cheers, Flo --
That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be If nothing blocks suspend. The reason to block suspend does not have I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is I'm not sure what you mean. -- Arve Hjønnevåg --
On Fri, 28 May 2010 02:18:06 -0700
Damn. I just want to put some abstract notion around this approach to
power saving.
But one could say instead of "direct" interaction, that every time a
suspend blocker is taken it is "on behalf of the user"?
So if a suspend blocker is taken, because a download is in progress,
it is on behalf of (direct, or indirect) user interaction.
If a suspend blocker is taken, because a key-press has to trickle up to
userspace, it is because of the user.
If a call comes in, a suspend blocker is taken, because the user wants
to receive incomming calls.
So suspend blockers are always a hint to the kernel, that the action is
"on behalf of the user" and it is therefore ok to not suspend the
The applications interacting with the user rely on other parts of
the system to block suspend then.
So it is (in general) not the application which determines if the user
interacts, but other sources (like input-drivers) and possible a
But couldn't you say, that the suspend blockers are always due to the
user? Or is this too narrow? I mean we talk about a device here. And
the device's purpose is it to serve the user. So it might be better to
say: suspend blockers annotate if a task is needed to fullfill the
devices purpose?
It is an easy to understand concept if one says, the device suspends if
it has nothing to do to further the cause.
I really want to get to a well expressed definition. suspend blockers
I'm not shure. But then again, i'm not too familiar with the kernel. It
sounds like it could save some duplication of effort to integrate
suspend into the idle-framework. "Purpose-fulness" could be just
Yeah. It's a "little bit" handwavy.
But the concept I have in mind:
int what_good_would_it_be_to_go_into_this_state( state )
{
/*
cur_state = get_current_state();
benefit = ( get_power_per_time(cur_state)
- get_power_per_time(state) ) *
get_expected_time_we_stay_there( state );
cost = ...We also use suspend blockers for work that is not visible to the user. The battery driver on the Nexus One wakes up periodically while charging to monitor the battery temperature and turn down the charge The user-space framework decides if the device is in an interactive mode or not (on Android phones the screen is off when it is not interactive). Input driver need to block suspend so the user-space I think it is more useful to say that suspend blockers annotate that some event needs to be processed even if the device is currently not I don't think we can plug suspend in as a cpu idle state. 1. we want to suspend even the cpu is not idle. 2. starting suspend will cause the cpu to not be idle. -- Arve Hjønnevåg --
On Fri, 28 May 2010 04:35:34 -0700 yeah. it would have to move out of the cpu-specific context. it would be a more general "system-state" thing. if the properties of the state's are well expressed, it does not matter that starting suspend will cause the cpu to not be idle, because our target-state(suspend) has better properties than any other state. (or maybe there needs to be a "state-transition-in-flight" flag.) if we take the "approximated duration of staying in that state" into account, we could provoke the pm-framework to always suspend if no constraint(i.e. blocker) is there. But really. I think I can't implement something like that. Also I really have _no_ idea how much work this would be. _And_ I am not really shure if this is a better approach than the current solution. Just an idea. Cheers, Flo --
It is, if the following two conditions hold simultaneously:
(a) Doing full system suspend is ultimately going to bring you more energy
savings than the (presumably lowest) idle state you're currently in.
(b) You anticipate that the system will stay idle for a considerably long time
such that it's worth suspending.
Thanks,
Rafael
--
I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions). -- Arve Hjønnevåg --
I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense. If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started. However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle. Thanks, Rafael --
What about timers? When you suspend timers stop (otherwise it is just a deep-idle mode), and this could cause problems. Some drivers rely on timers if the hardware does not have a completion interrupt. It is not uncommon to see send command x then wait 200ms in a some hardware specs. -- Arve Hjønnevåg --
QoS should be used in such cases. Rafael --
I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? -- Arve Hjønnevåg --
Assume for a while that you don't use suspend blockers, OK? I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers. Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend. Rafael --
It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can -- Arve Hjønnevåg --
Hi, Sorry if i'm asking something that was already said, but the thread is quite complex and i am not sure i have been able to grasp all of it. So, regardless of the SW implementation: -1) are you focusing on "good" HW or do you want to address all at the same time? -2) would you be ok with addressing "bad" HW as a special case, which requires workarounds and shouldn't dictate the overall design? -3) do you agree with the assumption that new HW is expected to get reasonably better and therefore workarounds at point 2) will progressively be confined to devices less and less common? -4) going to the definition of "good" and "bad" (maybe this should have come earlier in the list), can we define "good" HW as HW where: * suspend state and lowest achievable runtime idle state are basically equivalent from both power consumption and latency pov * the HW itself is properly able to track wakeup sources while it is in its deepest power state (as example OMAP3 has few independent wake-capable pads and a "wake ring" where one only gets the information that at least one of the pads belonging to such ring has received a wakeup) * wakeup sources can be dynamically masked at HW level, so that if a peripheral is not interesting, it doesn't wakeup the system (for example the camera button when the camera cover is closed) -5) HW that is not capable of properly generating asynchronous signal is most likely the cause for extra timers in kernel and it should be considered "bad" - in any other case having recurring in-kernel timers should be treated as bugs, if their existence is not tied to some meaningful work thanks, igor --
And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle. Thanks, tglx
Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore. -- Arve Hjønnevåg --
You still are addicted to the current suspend mechanism. :)
The whole point of doing it from idle in the form of a deep power
state is to avoid the massive sh*tload of work which is neccesary to
run the existing suspend code. But that needs runtime power management
and tweaks to avoid your timers waking you, etc.
The mechanism you want to use is: suspend no matter what, like closing
the lid of the laptop, but with a few tweaks around it:
1) An interrupt on a wakeup source which comes in while the suspend
code runs, i.e before you transitioned into wakeup mode, must
abort / prevent suspend.
2) Prevent another attempt to suspend before the event has been
delivered and the apps have signaled that they have not longer
any work to do.
As a side effect you confine crappy apps with that mechanism in
some way.
In the laptop case we do not want the tweaks as not going into suspend
might set your backpack on fire.
If I understood you correctly then you can shutdown the CPU in idle
completelty already, but that's not enough due to:
1) crappy applications keeping the cpu away from idle
2) timers firing
Would solving those two issues be sufficient for you or am I missing
something ?
Thanks,
tglxNo I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is Solving those two is enough for current android phones, but it may not be enough for other android devices. 1 is not solvable (meaning we cannot fix all apps), and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. Unrelated to Android, I also want to use opportunistic suspend on my desktop. -- Arve Hjønnevåg --
What prevents us from going into a disruptive mode from idle ? I don't We can mitigate it with cgroups and confine crap there, i.e. force I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro. Thanks, tglx
What do you consider disruptive? Disabling active interrupts? Stopping They may not be based on hardware that can get to the same power mode from idle as suspend. This could be acpi based hardware, it could be like the hardware we started with that did not have regular timers that could run in the low power mode, or devices could loose their I think using suspend is much simpler. It avoids having to worry about You do not need to sprinkle suspend blocker all over the distro for it to be useful. You can convert the existing auto-suspend code to use opportunistic suspend and all apps that don't use suspend blocker will behave as they do today while allowing apps to use suspend blockers to keep the system running after the auto-suspend timeout expired. -- Arve Hjønnevåg --
I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're So you're going to sprinkle this suspend blocker shite all over regular userspace? Why not instead work on getting apps to behave properly and idle when there's nothing to do? After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place. --
I have said several times, that regular user-space will not need to be Why would I add suspend blockers to the code I want to prevent running? -- Arve Hjønnevåg --
Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there. Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in. This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface. In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that. --
On Wed, 02 Jun 2010 12:21:28 +0200 Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*) I assume, in general, there are only a few reasons to shut down a machine: 1. One has to do maintainance on the hardware or somehow needs to interrupt the power supply. 2. One wants to save power. 3. One wants to go easy on the hardware. 4. ...? Obviously, for reason 1 we need to maintain the shutdown-paths indefinitely. But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox. It is a hard problem. But we have _no way of deciding any of this in If it is driver knowledge, then it goes into the driver. If it is platform knowledge, then it goes into the platform code. I think that is a clear requirement to keeping sanity. The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of "suspend blockers" scheme. Wouldn't it? Cheers, Flo --
Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace parts, but no, not otherwise ;-) But I've been doing that for pretty Make suspend an idle state and teach apps to go real quiet. (Then again, that only really works when regular network packets can Therefore I say, fix the worprocessor to not actually do anything if its not poked at -- not too hard, wordprocessors really don't need to do anything on their own, and you can do your last backup cycle when the window becomes invisible and stop the timer until the document changes again. Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own. Fix the friggin apps, don't kludge with freezing. You really only ever want to freeze broken apps. And even for those I would prefer it if I got notified some app is stupid, then I could either fix it, or choose not to use it. You can also teach cron to listen to dbus messages telling it about the screen state and postpone jobs -- but please make that a configurable thing, I really like all that work done at 4am when I'm (usually) not Well, at that point suspend is nothing more than an idle state, and platform code needs to somehow inform the idle state governor that active net connections need to prevent that idle state from being used. If you want to call that suspend blockers, then sure, but its a long way away from the explicit scheme proposed at the start of this thread. --
On Thu, 03 Jun 2010 09:40:02 +0200 Of course programs should be as smart as possible. But that is an orthogonal problem. Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level. Cheers, Flo --
Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well. --
On Thu, 03 Jun 2010 17:28:01 +0200 This is arguing on a very thin line. In fact it is becoming pointless. Suppose there were an RSS-feed plugin that signals events to an event Plugin. That event plugin could be either visual notification or sending audio-signals. But the RSS feed doesn't know what specific plugin it talks to. So screen off is _not always_ the right indicator. Sometimes it is, sometimes it's not. There would be a seperate infrastructure needed in the program to tell the different plugins that the core thinks everything should stop. How does the core knows when to stop? And then there probably need to be some kind of "suspend blockers" in the program. *g* Just solve it at the right level, so that the apps don't need to be infected with this shit. And this belongs between the iron and the apps. And it seems it needs to be some cooperative approach of kernel and userspace-framework as it isn't right to put that much policy in the kernel. I don't think it is a black and white thing, where you can just say "fix the friggin apps". And this is a really f*beep*ng serious point. (at least to me) Cheers, Flo --
Exactly, and that's what applications in the N900 do. For this to work reliably, you need these notifications (network disconnected, screen off) to be easily accessible, and even transparent to the application writer. I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs. When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever). We end up in exactly the same situation. -- Felipe Contreras --
On Sat, 5 Jun 2010 20:30:40 +0300 No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there." The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent. Cheers, Flo --
How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter. How would you do that with the dynamic PM approach? At regular So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers. -- Felipe Contreras --
On Sat, 5 Jun 2010 23:06:03 +0300 IIRC, the patches discussed have debugging infrastructure in If you think a little about it, it is. Because if the app wouldn't be usable at all, the bug wouldn't get fixed because the user wouldn't use it. Or not? Cheers, Flo --
We are not talking about debugging, we are talking about stats shown in user-space so that users can see the offending apps. It doesn't matter where the accounting is done, it would be at regular intervals and there's nothing that prevents the dynamic PM approach to offer I'm not sure what's your point here. One user not using a certain application doesn't prevent bugs to get fixed. In fact, less people using an app will cause less buzz, and less downloads, and less positive votes... which might wake up the author to think: hey, maybe I'm doing something wrong? Maybe I should really listen to those bug reports. Anyway, my point is that there's nothing special about 3rd party app stats with suspend blockers. -- Felipe Contreras --
We are talking about mainline here, there's no support for suspend blockers, so nothing is dropped. In the mind of everybody, suspend blockers is for opportunistic suspend, which only makes sense on sensible hw (not current x86). So in the mind of everybody, x86 should be out of scope for the analysis of suspend blockers. Are you seriously suggesting that one of the strong arguments in favor of suspend blockers is x86 usage (nobody agrees)? If not, then drop If I enable suspend blockers on my laptop, I have to modify my user-space. Otherwise my system will behave horribly. -- Felipe Contreras --
On Sat, 5 Jun 2010 20:44:24 +0300 I think they have an advantage over the 30-minute-screensaver-then-suspend that current desktops do. Because you can define what keeps the system up. I.e. the screensaver/powermanager is not limited to keyboard- and In the simplest case you have a shell script which takes a suspend blocker and reads from stdinput. When you write "mem" to it, it releases the suspend blocker and acquires it back again. Voila, forced suspend reimplemented on top of opportunistic suspend. That wasn't hard, was it? Cheers, Flo --
What prevents you from defining other things keeping the system up right now? Nothing. It's up to user-space to decide when to suspend. In fact applications already block suspend; Transmission has the Not hard, but still a modification of user-space, and a pretty bad one because it will prevent typical forced suspend, and typical suspend delaying (like with Transmission). Supposing the opportunistic suspend doesn't block the forced suspend, still, absolutely nothing will be achieved by enabling suspend blockers. If you want to take even a minimal advantage of suspend blockers you need serious modifications to user-space. Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers. -- Felipe Contreras --
On Sat, 5 Jun 2010 23:26:27 +0300 A solution for the desktop to deprecate having to shut down the machine would not be that bad, wouldn;t it? (Why have I to shut down my machine anyway?) In my opinion such a decision (when to shutdown) has to be guided by userspace knowledge. Future x86 hardware is to be fixed (as I read in this discussion), so using suspend blockers could be the tool of choice. But alright. Let's be a little bit more focused on the present situation: 1) There currently is no other solution. 2) It is a first stepping stone to bringing android to mainline. 3) Any "perfect" solution will emerge anyway. As there are so many people with so strong opinions engaged in this discussion, I'm confident. 4) If there is a better solution, android will shurely adapt it as soon as it is there. Cheers, Flo --
Crap. Once we have an userspace API we are bound to it. Period. Also there is no technical reason why the whole driver stack cannot Yes, and that needs cooperation and compromises from both sides and Sure, after we accepted the crap there is no incentive at all. Stop that advertising campaing already. No thanks, tglx --
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) Cheers, Flo (Sorry, crossfire. Caused by you answering in the wrong subthread. I know that you are engineering and not dismissing the problem. This was pointed at Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well") --
Aren't the container snapshot/resume people fighting the same set of problems here? --
On Wed, 02 Jun 2010 11:10:51 +0200 And virtualisation - its a big one for virtualisation because if you've got 1000 misbehaving guests generating 100 wakeups a second you've got a problem .... Alan --
