[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Brian Swetland on 28 May 2010 09:00 On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa <igor.stoppa(a)nokia.com> wrote: > ext Matthew Garrett wrote: >> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote: >>> The other vendors appear to be managing nicely without magic blockers. I >>> conjecture therefore there are other solutions. >> >> Actually, no. A badly behaved application will kill the N900's battery >> life. Nobody else has "managed nicely" - they've just made life harder for >> application developers and users, which may have something to do with the >> relative levels of market adoption of Maemo and Android. I'm not aware of >> any form of resource management framework in MeeGo either, so as far as I >> know it'll have exactly the same problem. > > It's true that a braindead app can kill the battery. > > However we provide a version of powertop that is tailored to the N900, there > is a nokia energy profiler meant to give graphical representation of the > battery current, there is htop available and you can even get the processor > activity visualized on the leftmost and rightmost keyboard backlight LEDS, > when in RD mode and with screen blanked. > > I would advice you to not start debating on company strategies, this is not > the right place. At a certain point, if one side of the argument is using "N900 / OMAP3 works just fine as is" (which has certainly been the case stated by a number of folks throughout these discussions), I think it's a little unrealistic to express shock that somebody argues the opposing point. I've personally avoided commenting on specific power management issues or properties of competitive platforms because it can easily be viewed as rather rude or unprofessional. (though in theory we all could benefit from any improvements to the kernel regarding power management, no?). I am quite willing to state that on both MSM and OMAP based Android platforms, we've found that the suspend blocker model allows us to obtain a lower average power draw than if we don't use it -- Mike Chan provided some numbers earlier in another thread in the trivial device idle case, the win is of course much larger in the case of several poorly behaved apps being active. I do think that everyone involved agrees that it is beneficial to educate users and developers in hopes that users will understand that some apps are non-optimal and developers will be encouraged to write better apps. I think we also all agree that striving to obtain the lowest power state at all times through cpu frequency scaling, runtime pm, drivers that aggressively clock/power down when idle, etc is a worthy goal. Some have argued that suspend blockers may deter further development in these areas, but I think this is unlikely -- power usage while the device is active and the user is interacting with it is just as critical as when it's not being used interactively. We (Android) certainly pursue aggressive low power optimization in both states. There appears to be some disagreement in terms of what one should do in the face of poorly behaved applications. The Android approach has been to both gather as much data as possible for education of user and developer and to mitigate the impact of poorly written apps on endusers, goals which are aided by the suspend blocker model. A reality of a mass market device with a completely open and unrestricted application development and distribution ecosystem is that there will be plenty of non-optimal apps available to users (Sturgeon's Law applies everywhere, after all). Worse yet, many of these non-optimal apps may be beloved by users for various reasons. I think there's value in trying to do the best you can power-wise even in the face of such horrible foes as the dreaded Bouncing Cows App that Matthew is fond of citing as an example. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Igor Stoppa on 28 May 2010 09:10 ext Theodore Tso wrote: > > > Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler. No, the strategy is to try to merge commercial and community needs. We do support signed repositories. The community has control on the public one. Members are encouraged to help by alpha/beta testing apps that are under development. They even organize testing marathons. > But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder. That's a wrong way to put it. By installing something on your phone you _do_ approve it. > I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository". What it meant is totally different. Regardless how much effort you put into twisting it. It means that different repositories provide different level of trust. As Debian user, I don't blame anybody other than myself is something I've pulled from unstable or experimental breaks my system. Debian by default doesn't ship with either unstable or experimental enabled. And using suspend blockers doesn't really solve the problem of who to trust to take the block and who not. Or we'll have to have suspend-blockers-blockers and so on ... Like it or not, QoS and resource management - in some form - are needed to allow trusted application to provide valuable feedback, while filtering requests from untrusted applications. You might want to add dynamic profiling and try to use some heuristic to have the system doing runtime evaluation of good vs bad applications, but still some discrimination mechanism will be required. igor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 28 May 2010 09:30 On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote: > On Fri, 28 May 2010 14:30:36 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote: > > > [Total kernel changes > > > > > > Ability to mark/unmark a scheduler control group as outside of > > > some parts of idle consideration. Generically useful and > > > localised. Group latency will do most jobs fine (Zygo is correct > > > it can't solve his backup case elegantly I think) > > > > > > Test in the idling logic to distinguish the case and only needed > > > for a single Android specific power module. Generically useful > > > and localised] > > > > I really don't like this.. > > > > Why can't we go with the previously suggested: make bad apps block on > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL > > Ok. Are you happy with the QoS being attached to a scheduler control > group and the use of them to figure out what is what ? Up to a point, but explicitly not running runnable tasks complicates the task model significantly, and interacts with fun stuff like bandwidth inheritance and priority/deadline inheritance like things -- a subject you really don't want to complicate further. We really want to do our utmost best to make applications block on something without altering our task model. If applications keep running despite being told repeatedly to cease, I think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and SIGTERM before that) and got ample opportunity to block on something. Traditional cpu resource management treats the CPU as an ever replenished resource, breaking that assumption (not running runnable tasks) puts us on very shaky ground indeed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 28 May 2010 09:30 On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa(a)nokia.com> wrote: > > What I consider plain wrong i to claim that since there are this many units > out, some code should be merged. I've never suggested that we should get a get-out-of-code-review-free card or be automatically merged based on shipping volume. Hell, I never thought we should even bother trying to merge wakelocks upstream, because I assumed that they'd be hated for not being the linux way (tm). Greg KH and others have spent a bunch of time shouting at me (or Google) that we should be doing this, and here we are giving it a go. At this point we've spent more engineering time on revising this one patchset (10 revisions to address various rounds of feedback) and discussion of it than we have on rebasing our working kernel trees to roughly every other linux release from 2.6.16 to 2.6.32 (which became much easier after switching to git). > A company needs to cut corners sometimes when making a product but this > should not affect upstream code. I will disagree that wakelocks are "cutting corners" (we certainly have some corner cutting code in our trees, because yeah, ship is compromise, but I don't believe wakelocks are an example). They're a real solution for real problems faced on real devices. Obviously not a solution that everyone here likes, and maybe they'll never end up in mainline as a result, but so far I haven't seen a counter proposed solution that seems to solve the same problem, avoid races, and be simpler/cleaner (at least to my eyes). >> I am quite willing to state that on both MSM and OMAP based Android >> platforms, we've found that the suspend blocker model allows us to >> obtain a lower average power draw than if we don't use it -- Mike Chan >> provided some numbers earlier in another thread in the trivial device >> idle case, the win is of course much larger in the case of several >> poorly behaved apps being active. > > That's very good. But if it is done in a conceptually flawed way, some > better solution should be considered for upstream merge. How is it flawed? Serious question. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 28 May 2010 09:30
On Thu, May 27, 2010 at 05:49:36PM -0700, Mike Chan wrote: > Even if we used the proposed QoS replacement, are there suggestions on > how to keep the cpu idle for longer than 2 seconds in Linux without > using suspend? I believe that the "Maximum idle time on 32-bit is 2 seconds" issue is solved in recent kernels. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |