Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote: This started because the Android people came to a meeting that was put together of various folks to try and sort of the big blockage in getting Android and Linux kernels back towards merging. I am interested right now in finding a general solution to the Android case and the fact it looks very similar to the VM, hard RT, gamer and other related problems although we seem to have diverged from that logic. Keep in mind, though, that a solution which is acceptable for Android has to include making sure that crappy applications don't cause the battery to get drained. There seem to be some people who seem adamently against this requirement. From the Android folks' perspective, this is part of what is required to have an open app store, as opposed to one where each application has to be carefully screened and approved ala the Apple iPhone App Store. Maybe it would be acceptable if there were an easy way THAT A USER AND NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad application, but realistically, it's much better if the solution can work well even in the face of crappy application. Having interacted with application programmers, I can assure you there are a lot of crappy application programmers out there, and they vastly outnumber us kernel developers. (See as exhibit A all of the application programs who refuse to use fsync, even though it's going to wipe them out on all new modern file systems, including btrfs.) We need to agree on the requirements up front, because otherwise this is going to be a waste of everyone's time. And if we can't get agreement on requirements, I'd suggest appealing this whole thing to Linus. Either he'll agree to the requirements and/or the existing implementation, in which case we can move on with our lives, or he'll say no, in which case it will be blately obvious that it was Linux developer community who rejected the Android approach, despite a fairly large amount of effort trying to get something that satisfies *all* of the various LKML developers who have commented on this patch, and we can continue with Android having kernel which is different from mainline --- just as many other embedded companies have patches which are utterly required by their products, but which have been judged Too Ugly To Live In Mainline --- and we can also move on and get on with our lives. - Ted P.S. Keep in mind how this looks from an outsider's perspective; an embedded manufacturer spends a fairly large amount of time answering one set of review comments, and a few weeks later, more people pop up, and make a much deeper set of complaints, and request that the current implementation be completely thrown out and that someone new be designed from scratch --- and the new design isn't even going to meet all of the requirements that the embedded manufacturer thought were necessary. Is it any wonder a number of embedded developers have decided it's Just Too Hard to Work With the LKML? -- 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 3:55 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: This started because the Android people came to a meeting that was put together of various folks to try and sort of the big blockage in getting Android and Linux kernels back towards merging. I am interested right now in finding a general solution to the Android case and the fact it looks very similar to the VM, hard RT, gamer and other related problems although we seem to have diverged from that logic. I think that the suspend block model can be viewed as a constraints problem (similar to some of things things you've been sketching out in these threads), but I think we (Google/Android) view it as more of a state constraint (don't enter suspend) than a latency constraint. We think there's a need for these constraints both from the driver side and userspace side, and that these constraints are not tied to processes (multiple entities in one process may have different constraints at different times or multiple processes may be working together to accomplish some goal under a single constraint -- at least both cases exist in the Android system as it ships today). The exact naming of the API is not terribly important to us. The first thing we spent a bunch of time discussing last summer when Arve first looked into sending wakelocks upstream was changing the name because many objected to wakelock for various reasons. Being able to have userful statistics (which drivers/processes/etc held which wakelock for how long, how many times, etc) is important to us. While we want to do the best we can in the face of poorly written apps, we also want to educate users and developers about which apps are contributing to their poor battery life -- so users can decide to uninstall an app if its usefulness does not justify its impact on battery life and application developers can be more aware of what the cost of their app is to endusers. As an example, http://frotz.net/misc/battery-stats-unplugged.txt contains a dump from the battery service aggregating wakelock usage, cpu usage, and sensor device usage of processes (#: sections) on my phone the other day for a ~3 hour period. This data is presented visually to the enduser in a what's using my battery feature of the platform. realtime refers to wall clock time here and uptime refers to not-in-suspend execution time. Brian -- 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, 2010-05-27 at 15:19 -0400, Alan Stern wrote: On Thu, 27 May 2010, Peter Zijlstra wrote: I still don't see how blocking applications will cause missed wakeups in anything but a buggy application at worst, and even those will eventually get the event when they unblock. What seems to be the confusion? During forced suspend, applications are block because they are frozen. When an event occurs, the application is notified somehow. But it can't respond because it is frozen. Hence the event remains sitting in a kernel queue and the system goes ahead and suspends anyway. The application doesn't get thawed until the system wakes up at some indefinite time in the future. If the kernel is awake to put things in queues, we're clearly not suspended and userspace is running ?! -- 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 Wed, May 26, 2010 at 12:02 PM, Florian Mickler flor...@mickler.org wrote: So why again was this such a great scheme? Go fix your userspace to not not run when not needed. Hi Peter! This was already mentioned in one of these threads. The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants. I don't see this as a valid point. Everyone can run a different kernel where nothing will just work. Are you aiming protection against that as well? ~Vitaly -- 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)
2010/5/26 Arve Hjønnevåg a...@android.com: Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. But if this feature gets merged, I bet you'll find another 100 reasons to not fix the actual issue. I wouldn't say so if you haven't provided the irrelevant points already, like replacing x86 hardware. You're trying to merge the approach which makes the bad way of handing things the easiest way. This shouldn't get in as it is IMO. ~Vitaly -- 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 Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote: This is not protection. This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek) Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;) ~Vitaly -- 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 Wed, 26 May 2010 14:01:49 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote: This is not protection. This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek) Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;) ~Vitaly Because he is using a robust kernel that provides suspend blockers and is preventing the vampire from sucking power? Most users don't even grasp the simple concept of different programs. They just have a device and click here and there and are happy. Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. Cheers, Flo -- 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)
hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. -- balbi DefectiveByDesign.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 Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Cheers, Flo -- 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)
Hi, On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. and that's enough to push hacks into the kernel ? I don't think so. Do it like apple and prevent multi-tasking for any non-apple applications :-p -- balbi DefectiveByDesign.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 Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Provide the developers and users with tools. Notify the users that their phone is using power at an unadvised rate due to proglet $foo. Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue. -- 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 Wed, 26 May 2010 15:35:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: Hi, On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. and that's enough to push hacks into the kernel ? I don't think so. Do it like apple and prevent multi-tasking for any non-apple applications :-p :) It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. All points about the impact on the kernel have already been raised. So you should be happy there. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel. And as for the quality of the hack: I think you find this ugly, just because you don't like the concept of degrading user space guaranties on timers and stuff. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource power. If a user space program needs the traditional guaranties for functioning properly, it needs to take a suspend blocker. But _THEN_ it better be well behaved. This is a kind of contract between userspace and kernelspace. On the other hand, if I don't need these traditional guaranties on timers and stuff, I don't have to know device specific things about power consumption. I can just use whatever facilities the programming language provides without needing to worry about low level details. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). Cheers, Flo -- 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 Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. You almost always need to hack the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way. ~Vitaly -- 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 Wed, 26 May 2010 14:41:29 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Provide the developers and users with tools. Notify the users that their phone is using power at an unadvised rate due to proglet $foo. Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue. Yeah. And I personally agree with you there. But this is a policy decision that should not prevent android from doing it differently. The kernel can not win if it does not try to integrate any use of it. After all, we are a free comunity and if someone wants to use it their way, why not allow for it? (As long as it does not directly impact other uses) The best solution wins, but not by decision of some kernel development gatekeepers, but because it is superior. There are no clear markings of the better solution. Time will tell. Cheers, Flo -- 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 Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote: It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. That's exactly what we always do. If we were not to do so, the kernel would be a bloated incoherent piece of crap. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. I really think we should not do so. Let them help in fixing the real issue instead of creating a new class of userspace that is more important than another. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource power. How is userspace without suspend blockers not accountable? We can easily account runtime and in fact have several ways to do so. -- 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 Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: The kernel can not win if it does not try to integrate any use of it. If we'd integrate every patch that came to lkml, you'd run away screaming. We most certainly do not want to integrate _any_ use. -- 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)
Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ? - You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this - You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1] That maps onto two existing ideas Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like setpidle(getpid(), something); exec() where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API. And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone. Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers. Alan -- [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) -- 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)
Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. That seems to me to be conflating models of behaviour and implementations. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). You would do better to concentrate on technical issues that the assignment of malicious intent to other parties. Alan -- 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 Wed, 26 May 2010 14:55:31 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. You almost always need to hack the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way. ~Vitaly I don't think that the in-kernel suspend block is a bad idea. You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not. Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a suspend as soon as possible semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away). Cheers, Flo -- 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 Wed, 26 May 2010 15:07:27 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: The kernel can not win if it does not try to integrate any use of it. If we'd integrate every patch that came to lkml, you'd run away screaming. We most certainly do not want to integrate _any_ use. We most certainly do want to integrate any use that is not harmful to others. I don't buy the argument that this is harmful. Cheers, Flo -- 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 Wed, 26 May 2010 14:19:42 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). You would do better to concentrate on technical issues that the assignment of malicious intent to other parties. Alan This was nothing the kind of! He explicitly said this: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. And I responded that if the kernel would do this, then that would be a _big_ plus for attracting 3d party programs. I had no intent in attacking anyone or putting word's in someones mouth. Sorry if this was unclearly written. Cheers, Flo -- 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)
Alan, On Wed, 26 May 2010, Alan Cox wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. I completely agree. We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist. In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code. Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap! That's not a solution, that's just capitulation. It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea. Thanks, tglx -- 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 Wed, 26 May 2010, Florian Mickler wrote: I don't think that the in-kernel suspend block is a bad idea. You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not. That's not how it works. Drivers aren't supposed to abort unconditional suspend -- not without a really good reason (for example, the device received a wakeup event before it was fully suspended). In short, suspends should be considered to be _always_ possible. Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a suspend as soon as possible semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away). That's different. Suspend blockers could block (not abort!) regular suspends, just as they do opportunistic suspends. But why should they? I mean, if userspace wants to initiate a suspend that is capable of being blocked by a kernel suspend blocker, then all it has to do is initiate an opportunistic suspend instead of a normal suspend. Alan Stern -- 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 Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. -- 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 Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do echo opportunistic /sys/power/policy How about we don't merge that junk and don't give you the opportunity to do silly things like that? :-) -- 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)
Alan Cox a...@lxorguk.ukuu.org.uk writes: [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) Completely agree with this. I used the static/dynamic names out of habit, but since on most embedded devices, there is really no difference in hardware power state, I agree that the difference is only a matter of wakeup latency. Kevin -- 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)
Hi, On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. I completely agree. We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist. In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code. Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap! That's not a solution, that's just capitulation. It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea. I couldn't agree more with both of you. I also have stated that a powertop application with a fancy UI would do the job. Also building some sort of power estimations on the SDK would allow the developer the have fast feedback about potential power consumption caused by his app on the device. On top of that, the app stores can use the same power estimation technology to rate apps automatically and even reject apps that are wy too badly written. I also feel that kernel shouldn't have to deal, fix, hide bad behavior from apps. -- balbi -- 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)
I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. It is a contract - but not the right one. You are removing autonomy from the kernel when only the kernel can measure the full picture and when the kernel is actually supposed to be responsible for resource management. On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker. Even the the model is wrong. I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android Disagree. It's an arbitary and misleading divide that happens to reflect a specific vendors current phones. Worse yet it may not reflect their own future products. It assumes for example that their is some power level that is 'suspend' that is singular, application understood and can be effectively user space managed. Big assumptions and not ones that seem to be sensible. It also breaks another rule - when the hardware changes your application blocker policies will be wrong. Do you want multiple hand optimised copies of each app ? Take a look at what happened to CPU designs where the assumption was you'd recompile the app for each CPU version to get any useful performance. If you are instead expressing it as must be able to respond in time X and must be able to wake up from an event on an active device then your interface is generic and hardware independant. If bouncing cows says 'need to wake up every 0.3 seconds you want the kernel to decide how best to do that. It will vary by hardware. On todays desktop PC thats probably a low power state limit. On some current embedded hardware it might be a special deep sleep mode. On one or two devices it might be 'suspend'. It might also be that the properties have been set to 2 seconds already so it gets told it can't have 0.3. The app cannot be allowed to know platform specific stuff or your portability comes apart and you end up with a disaster area where each app only comes on a subset of devices. Express the requirement right and you get a simple clean interface that continues to work. Express it wrong and you get a mess. userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do Thats a very big hammer and it doesn't express what I actually want, which is to allow the cows to run as efficiently as possible. echo opportunistic /sys/power/policy in the first place. But you can do this properly by having a per process idle requirement, and that can encompass things like hard real time as well (or even gaming). The suspend blockers break all the global policy, don't solve real time and don't allow for sensible expansion models. They don't solve our existing wakeup versus device problems either. How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1]) In this environment the problem cannot occur in the first place unless there are kernel code bugs, if there are then they are in GPL code and can be fixed. But you are mixing up interfaces and implementations which I find is usually a bad idea. Doing the right thing badly gives you an interface to an implementation you can later fix. Doing the wrong thing well leaves you stuck down a hole. p.s.: d...@schatten /usr/src/linux $ grep -r setpidle . Yes I know - no point having a new function which has an in use name is there ? It's trivial to add per process idling or wakeup requirements. Alan -- 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 Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. -- 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 Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. -- 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 Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer. Cheers, Flo -- 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 Wed, 26 May 2010 17:47:35 +0200 Florian Mickler flor...@mickler.org wrote: On Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer. Cheers, Flo p.s.: also they encourage me to think more before answering. -- 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)
Florian, On Wed, 26 May 2010, Florian Mickler wrote: On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker. This is an option which they currently don't have. Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it. suspend blockers are completely backwards as they basically disable the kernels ability to do resource management. Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already. So what the kernel needs to know to make better decisions are things like: - how much slack can timers have (exisiting interface) - how much delay of wakeups is tolerated (missing interface) and probably some others. That information would allow the kernel to make better decisions versus power states, grouping timers, race to idle and other things which influence the power consumption based on the hardware you are running on. I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do echo opportunistic /sys/power/policy in the first place. This optionally being badly written, who cares? is a new feature the kernel can provide to applications. It's a misfeature which the kernel should not provide at all. It sends out the completely wrong message: Hey, we can deal with your crappy code, keep on coding that way. While this seems to sound cool to certain people in the mobile space, it's completely backwards and will backfire in no time. The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Thanks, tglx -- 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)
The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week. A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess. Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ? Alan -- 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 Wed, 26 May 2010 19:02:04 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week. A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess. Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ? Alan Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? Cheers, Flo -- 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 Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote: Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap? ~Vitaly -- 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)
suspend blockers are completely backwards as they basically disable the kernels ability to do resource management. I don't think this is a defect in the approach but the point of it. I think it's both. It's the point of it, and that itself is a defect. Its designed wrongly. drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on? The Linux approach is to do the job right. That means getting the interface right and so it works across all the interested parties (or as close as we can get). - how much delay of wakeups is tolerated (missing interface) Doesn't solve the segregation problem and is probably overkill for most applications. I see this as an orthogonal thing (i.e. not affecting this merge). The key question that matters for suspend management is 'what wakeup delay is tolerated'. So it's absolutely fundamental. True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users. This is the Linux way of doing things. It's like the GPL and being shouted at by Linus. They are things you accept when you choose to take part. Google chose to use Linux, if they want a feature upstream then the way you get it there is to figure out how to solve the real problem and make *everyone* (within reason) happy. We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap. Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits. So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs) Alan -- 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 Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ? Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. - You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this - You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1] That maps onto two existing ideas Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. setpidle(getpid(), something); exec() where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API. And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone. Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers. What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel? Alan -- [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable. My app simply should not have to know this sort of crap, that's the whole point of an OS. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win. Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. Opportunistic suspend isn't special. Suspend is just a very deep idle. In fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states. User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy. Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with. Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends. Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly. So what are expressing 'I am using device 'screen' please keep it live' (which may or may not block suspend - see OLPC). I guess your display server and kernel support manage this bit. 'I want the photo to appear in a resonable timescale' (latency). It's not a suspend question - an imaginary non suspend idle mode with a 20 second latency would be just as annoying yes ? At the moment we have a very real bigger problem that your problem is part of. - Hard real time people want to be able to limit the CPU sleeping behaviour based upon what tasks are running - Certain gaming types want their boxes to be good power citizens except when committing digital mass murder. Right now that involves wrapping the game in a script with bits occurring as root and that generally breaks if the game crashes so the script doesn't run nicely on exit - Virtual machine people desperately want to see latency data to help schedule stuff in a power efficient manner. In a virtual machine environment
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk: On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable. Are you still talking about Linux suspend? If you can enter S3 from idle and still wake up for the next timer or interrupt, then do that. Suspend blockers should have not effect on this. My app simply should not have to know this sort of crap, that's the whole point of an OS. Most apps does not have to know about this with opportunistic suspend either. If the user is interacting with the device, we don't suspend. If your apps needs to run when the user is not interacting with the device, then you can block suspend. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win. Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. Opportunistic suspend isn't special. Suspend is just a very deep idle. In Suspend as it is currently implemented in Linux is special. Regular timers stop, and only specially marked wakeup events can bring the system back to the normal state. fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states. User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy. On a phone this is not the case. The user manually can toggle the screen on and off, and we may or may not enter suspend when the screen is off. If we forced suspend when the user turned the screen off, we could miss phone calls. Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with. Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends. Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly. I don't think a latency api is the right way to express this since the only latency values we
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote: Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap? ~Vitaly Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org. So why don't we do what we always do? Improve existing interfaces step by step? Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation. Cheers, Flo -- 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 Wed, 26 May 2010 23:09:43 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap. Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits. So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs) Alan I'm not interested in abusing processes. I just think, this is in limbo for too long already. Just decide something. One way or the other. The world will continue. Cheers, Flo -- 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
