On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa <igor.stoppa@xxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
