ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #03967
Re: Catching CPU run-aways on Touch
On Wed, Sep 4, 2013 at 2:04 PM, John Lenton <john.lenton@xxxxxxxxxxxxx> wrote:
> On Wed, Sep 4, 2013 at 12:25 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
>>
>> 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?
>
> I might be missing something, but the load average (from
> /proc/loadavg) is the overall CPU usage for three given amounts of
> time (a minute, five minutes, fifteen minutes). Much faster than
> parsing all of proc:
>
> /proc/loadavg
> The first three fields in this file are load average
> figures giving the number of jobs in the run queue
> (state R) or waiting for disk I/O (state D) averaged
> over 1, 5, and 15 minutes. They are the same as the
> load average numbers given by uptime(1) and other pro‐
> grams. The fourth field consists of two numbers sepa‐
> rated by a slash (/). The first of these is the num‐
> ber of currently runnable kernel scheduling entities
> (processes, threads). The value after the slash is
> the number of kernel scheduling entities that cur‐
> rently exist on the system. The fifth field is the
> PID of the process that was most recently created on
> the system.
>
> (from 'man proc')
Sure, the load average is perfectly fine, but according to man proc,
/proc/$PID/stat has:
utime %lu (14) Amount of time that this process has been
scheduled in user mode, measured in clock ticks
(divide by sysconf(_SC_CLK_TCK)). This includes
guest time, guest_time (time spent running a virtual
CPU, see below), so that applications that are not
aware of the guest time field do not lose that time
from their calculations.
stime %lu (15) Amount of time that this process has been
scheduled in kernel mode, measured in clock ticks
(divide by sysconf(_SC_CLK_TCK)).
and we require the total CPU usage (in ticks) over all processes to
come up with the per-process percentage as I understand it. Or am I
missing something?
Thanks,
Thomas
References