lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: /proc/uptime idle counter remains at 0
    On Mon, 11 May 2009 07:23:58 +0100 (BST)
    Michael Abbott <michael@araneidae.co.uk> 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 <schwidefsky@de.ibm.com>

    --
    blue skies,
    Martin.

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



    \
     
     \ /
      Last update: 2009-05-11 09:37    [W:0.025 / U:0.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site