Re: /proc/uptime idle counter remains at 0

[Jan Engelhardt]

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?

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 (%)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/