On Mon, May 17, 2010 at 2:27 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > > This kind of rogue app will also kill my CPU performance. For rogue > CPU-hog apps, we use _tools_ to find and fix this kind of problem: > top, renice, kill, etc. that use features of the scheduler to find > and/or solve the problem. > > For rogue apps that affect PM, what is being proposed is to bypass the > root causes (timers, scheduler, activity, etc.) and just freeze the > apps. > > Rogue CPU-hog apps are generally not tolerated. The problems are > found using tools and fixed (or removed.) Why should we do any > different for rogue power-hog apps? > > Maybe the tools aren't as good for finding power-sucking apps. > Then we should be focusing on the _tools_ instead of masking the > problem. Mass market consumer devices that allow arbitrary app installation are a fun challenge because many (most?) users are not aware of the low level details here or why one app is bad and another is good. They often don't even know which app of N they installed is causing their problems. We're providing this information as we can to help users understand which apps are using cpu or preventing suspend, via the battery usage UI. We try to provide even more detailed information to developers so they can test and adjust for poor cpu/power usage. We are also doing our best to behave well even in the face of poorly written apps. I think you need to do both -- provide tools and education, but also make the best of things. If I can make a device with a poorly written app make it over a day of standby instead of 4-8 hours of standby, that has immediate benefit to the user, for example. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
