lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /proc/uptime idle counter remains at 0
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-05-11 09:27    [from the cache]
©2003-2011 Jasper Spaans