ubuntu-phone team mailing list archive

[Evan Dandrea <ev@xxxxxxxxxx>]

On 4 September 2013 12:25, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
> +1, the respective grace/timeout period would need to be determined
> from empirical data, too.

Agreed.

>> With the application lifecycle work, background applications will be
>> suspended and get no CPU time at all, so this check will only apply to
>> system processes.
>>
>
> True, but to determine the CPU percentage, we would need to have the
> CPU usage of all processes for a certain amount of time available.
> That is, essentially parsing all of proc iiuc. I'm hopefully wrong,
> but if not, could we resort to an approach that just considers the
> per-process user and system CPU time consumed in a given time
> interval?

Yes, I didn't mean to imply that we filter them out from any
calculation, but rather that we do not consider reporting them because
they'll either be foregrounded or suspended.

> Yup, but we should start over with measuring before we start
> classifying CPU usage.

Yes, definitely. It absolutely makes sense to run this in a
measure-only mode before we flip on the out-of-control killer.

> I would rather want to keep it out of whoopsie and integrate it with
> the component implementing the lifecycle policy for two reasons.
> However, if we are only considering to monitor system/session
> services, it would be ok to start over with whoopsie. However, I would
> prefer an implementation that is easily reusable by other components
> (Mir/Unity8).

Yes, and I believe this was suggested in the prior discussion by
Steve. I forgot to include it in the summary; sorry.

I am definitely behind this living in the lifecycle policy system.
While whoopsie is long-running and does operate in the area of error
reporting, it does not already have code to poke at the brains of
processes. That's all handled by apport via the kernel core pipe. So
it felt like scope creep to me.

> Indeed. I think we would need to consider visibility (in terms of UI)
> and ANR in the policy and the component implementing the lifecycle
> policy, i.e., Mir and Unity8, is a better place to implement the
> behavior.

Definitely, though care still would need to be taken for things like
GCC on the desktop.