ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxx>]

Hi guys,

On Wed, Sep 04, 2013 at 04:06:33PM +0100, John Lea wrote:
> Hi All,  two questions about the proposal below:

> 1) How do we differentiate between background non-ui processes that
> are legitimately using 100%+ of the CPU for extended periods of time
> and runaway processes?

This is indeed a key question; and as I've commented to Evan, there simply
is no purely quantitative measure that is going to give you a reliable
answer.  You can't tell that a process is a runaway process just by seeing
how much CPU it uses or for how long; in some cases, a background process is
legitimately doing calculations that are going to use the whole CPU for a
long time, and only a developer can make the judgement call about what level
of CPU usage is "reasonable" for a given process performing a given
operation.

I don't see any shortcuts around the fact that identifying runaway processes
is going to require manually sifting through reports to identify possible
problems.  I think we should have a very clear idea of how we expect to make
use of any data we're gathering on this front, before spending engineering
effort on trying to gather it.

That said, one thing that we *could* make use of immediately would be better
tools for diagnosing processes that are using too much CPU in cases where we
know the system is supposed to be idle.  This would primarily be interesting
for integration tests in the lab, rather than crowdsourced submissions to
errors; but such tools would also be useful later for analyzing any reports
from processes that we *do* suspect of being runaways.

On Wed, Sep 04, 2013 at 08:25:23PM +0200, Thomas Voß wrote:
> That's indeed quite interesting and I don't think we are able to come
> up with a meaningful heuristic for version 1. (Evan, please correct me
> if I'm wrong). However, for anything user visible, ANR is the right
> approach to identify apps that are using 100% CPU _and_ are
> unresponsive while calculating.

Right - the definition of a misbehaving foregrounded app is one that doesn't
give the user what they want in a timely manner, or that the user notices
drains the battery while doing so.  There are already other, more reliable
feedback channels for such problems: the user complains to the app
developer.  Measuring CPU usage is always going to be a poor proxy.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature