linux-kernel - Re: [PATCH] Re: /proc/uptime idle counter remains at 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090511093512.38ba9b70@skybase>
Date:	Mon, 11 May 2009 09:35:12 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Michael Abbott <michael@...neidae.co.uk>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Re: /proc/uptime idle counter remains at 0

On Mon, 11 May 2009 07:23:58 +0100 (BST)
Michael Abbott <michael@...neidae.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@...ibm.com>

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/