ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Sep 5, 2013 at 3:49 PM, Colin Ian King <colin.king@xxxxxxxxxxxxx> wrote:
> On 05/09/13 14:39, Thomas Voß wrote:
>> On Thu, Sep 5, 2013 at 3:25 PM, Joe Talbott <joe.talbott@xxxxxxxxxxxxx> wrote:
>>> On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
>>>> On 09/05/2013 12:42 PM, Colin Ian King wrote:
>>>>> On 05/09/13 10:33, Colin Ian King wrote:
>>>>>> On 05/09/13 10:23, Evan Dandrea wrote:
>>>>>>> Stuart Langridge brought up an interesting idea for this on IRC, which
>>>>>>> I'm copying here rather than having more side discussions:
>>>> [...]
>>>>
>>>> Oops, I should have read the whole thread before posting my previous
>>>> e-mail. :-)
>>>>
>>>>> Anyhow, I still think myAppIsRunning() is open to abuse as it will in
>>>>> time be lavishly added to all sorts of tight loops that suck CPU, which
>>>>> just adds more overhead on the long run.
>>>>
>>>> Well, if we don't have a myAppIsRunning() API, apps can simply busy-loop
>>>> whenever they want, so I don't see much harm in adding this API.
>>>> We could also protect it with apparmor, so that the usage of this API
>>>> must be explicitly declared in the application's manifest file (and then
>>>> we could question whether the app has any reason to use it).
>>>>
>>>> Note however that this would still solve the issue of detecting apps who
>>>> use too much CPU time because of some bugs, which I think was the
>>>> original goal.
>>>
>>> Would a watchdog sort of timer work better here?  One where the OS sends
>>> a signal to a high CPU usage app and if the app doesn't respond to the
>>> signal we have a better clue that something is amiss.
>>>
>>
>> Hmmm, effectively extending the ANR approach to non-UI bits. That is
>> interesting idea. Admittedly, an app could work around that, too, but
>> hey :) Further extending on the idea: Whenever we identify a process
>> that is using too much CPU over a certain period of time, we start
>> ptrac'ing it and send over a SIGXCPU. If the process hasn't setup a
>> signal handler for that signal and we find out (waitpid and friends),
>> we can assume that the process is either not behaving in the Ubuntu
>> way _or_ something is wrong and we SIGKILL. Alternatively, we could
>> use SIGUSR1/SIGUSR2.
>>
>> Makes sense?
>
> Thinking a bit laterally here, when my HDD or SSD fills up on my desktop
> I get a pop-up message warning me so that I can deal with the low
> storage issue.  CPU is the same, if it is being abused then perhaps we
> need to alert the user. Maybe a pop-up to say that a process is
> misbehaving and if it's not handled then we kill the rouge process.
>

I think the main issue is being robust against outliers. CPU usage
peaks are okay, and if we report too many false positives, the user
will be annoyed (for a good reason :)). So I would try to keep the
user out of the equation as much as possible.

Thomas

>>
>>   Thomas
>>
>>> Thanks,
>>> Joe
>>>
>>> --
>>> Mailing list: https://launchpad.net/~ubuntu-phone
>>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp