Re: /proc/uptime idle counter remains at 0

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Mon, 11 May 2009 02:46:03 +0200 (CEST)
Jan Engelhardt <jengelh@medozas.de> 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,
   Martin.

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