[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Re: /proc/uptime idle counter remains at 0
On Mon, 11 May 2009 07:23:58 +0100 (BST)
Michael Abbott <> wrote:

> On Mon, 11 May 2009, Jan Engelhardt wrote:
> > On Sunday 2009-05-10 19:12, Martin Schwidefsky wrote:
> > >> So, were the updates to uptime.c missed, or do we now live on with
> > >> /proc/uptime constantly having 0?
> Please, let's not do this -- it breaks my instrument (which currently
> thinks the processor is overloaded).

Hmm, bad..

> I have to confess I don't really understand the logic of what's going on
> here -- in particular, what does the idle process do other than account
> for time when the processor has nothing useful to do? It does seem to me
> now that the .utime and .stime fields are now less than useful -- maybe
> they can be deleted now?

The idle task does not just sleep, it will do "real" work, e.g. softirq
handling for interrupts / network traffic. This is added to the stime
field of the idle process and it does carry some information. And
deleting these fields won't be possible as utime/stime are needed for
the other processes as well. To selectively remove them for the idle
process doesn't make sense to me.

> I've always assumed that the second field of /proc/uptime was a simple
> measure of time not spent doing real work, in other words a crude measure
> of spare CPU resources. My instrument basically uses the the two fields
> of this file to compute a measure of CPU loading so it can raise an alert
> if the CPU doesn't have enough spare (idle) capacity.

But it wasn't.. the old style stime of idle is a mixture of true idle
time and some system time.

> So as a simple solution, I've attached a patch where I just copy the idle
> field processing from fs/proc/stat.c. I expect that on a multi-processor
> machine things may not be quite so simple -- as up time is in elapsed
> wall-clock time, then so should idle time be, so we probably need to also
> divide by the number of processors. Afraid I don't have a multiprocessor
> test system, and /proc/stat seems ok, so I've not made this refinement.

Yes, on a multiprocessor in particular with cpu hotplug you need
additional information to be able to interpret the number. I still like
the patch because it gives the field a defined semantic: the total time
spent by the activated cpus waiting for work measured in cputime terms.
The semantic is still different from the old style number though.

For whom it matters:
Acked-by: Martin Schwidefsky <>

blue skies,

"Reality continues to ruin my life." - Calvin.

 \ /
  Last update: 2009-05-11 09:37    [W:0.063 / U:7.384 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site