[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: /proc/uptime idle counter remains at 0
    On Mon, 11 May 2009 02:46:03 +0200 (CEST)
    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?
    > >
    > >The second paragraph from git commit 79741dd tells you more about this:
    > >
    > >In addition idle time is no more added to the stime of the idle
    > >process. This field now contains the system time of the idle process as
    > >it should be. On systems without VIRT_CPU_ACCOUNTING this will always
    > >be zero as every tick that occurs while idle is running will be
    > >accounted as idle time.
    > >
    > >The point is the semantics of the stime field for the idle process. The
    > >stime field used to contain the real system time (cpu really did
    > >something) of the idle process plus the idle time (cpu is stopped).
    > >After the change the field only contains the real system time. Which is
    > >ihmo much more useful, no?
    > Actually doing something while idle would then probably be limited to
    > CPUs that have no HLT instruction/state, like ancient i386, right?
    > Are the semantics of /proc/uptime (more-or-less standardsly) defined
    > somewhere, e.g. written down into a manual page?

    Not really, the second field is the stime of the idle process for the
    boot cpu. This is a mixture of the time spent in idle doing work and
    waiting on hlt. In an smp system with multiple task_structs with stime
    fields it makes even less sense. The field is ill defined.

    > Nevertheless, one could argue that, hypothetically, some people or
    > their scripts interpreted the second field as the time that there was
    > no process running; sort of a minimalistic way to tell the average
    > system use in % beyond the 1/5/15-loadavg counters. So the field could be
    > kept, or now that 2nd place displays 0.00, be re-added. Depending on
    > how “standardized” /proc/uptime's format is, the 0.00 could either
    > stay as second position or move to third position.
    > > cat /proc/uptime
    > 496468.50 432205.41
    > > bc -l <<<'100-(432205.41*100/496468.50)'
    > 12.94 (%)

    That would work on a uni-processor. On an smp with cpu hotplug you'll
    get interesting results..

    blue skies,

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-05-11 09:27    [W:0.040 / U:76.404 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site