From killing@gromit.multiplay.co.uk  Sun Jan 19 17:42:39 2003
Return-Path: <killing@gromit.multiplay.co.uk>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CB61237B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 19 Jan 2003 17:42:39 -0800 (PST)
Received: from gromit.multiplay.co.uk (dsl-212-135-219-185.dsl.easynet.co.uk [212.135.219.185])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 97E7043F18
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 19 Jan 2003 17:42:38 -0800 (PST)
	(envelope-from killing@gromit.multiplay.co.uk)
Received: from gromit.multiplay.co.uk (localhost.multiplay.co.uk [127.0.0.1])
	by gromit.multiplay.co.uk (8.12.6/8.12.6) with ESMTP id h0K1f5aE016436
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 20 Jan 2003 01:41:05 GMT
	(envelope-from killing@gromit.multiplay.co.uk)
Received: (from root@localhost)
	by gromit.multiplay.co.uk (8.12.6/8.12.6/Submit) id h0K1f4lu016401;
	Mon, 20 Jan 2003 01:41:04 GMT
Message-Id: <200301200141.h0K1f4lu016401@gromit.multiplay.co.uk>
Date: Mon, 20 Jan 2003 01:41:04 GMT
From: killing@multiplay.co.uk
Reply-To: killing@multiplay.co.uk
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: top reports inaccurate cpu usage
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         47235
>Category:       bin
>Synopsis:       top(1) reports inaccurate cpu usage
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan 19 17:50:02 PST 2003
>Closed-Date:    Thu Sep 25 15:50:18 UTC 2008
>Last-Modified:  Thu Sep 25 15:50:18 UTC 2008
>Originator:     Steven Hartland &
>Release:        FreeBSD 5.0-RELEASE i386
>Organization:
Multiplay UK
>Environment:
System: FreeBSD gromit.multiplay.co.uk 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003 root@hollin.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
Ibm 370 thinkpad 450Mhz 128MB RAM


>Description:
	When using top the totals at the top and the totals of the
	processes differ wildy e.g
last pid: 13371;  load averages:  1.02,  0.88,  0.51                                           up 0+02:22:35  01:33:35
35 processes:  2 running, 33 sleeping
CPU states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Mem: 27M Active, 58M Inact, 24M Wired, 5220K Cache, 22M Buf, 5324K Free
Swap: 235M Total, 48K Used, 235M Free

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
13370 root     132    0 10616K 10084K RUN      0:02 55.35%  5.27% cc1
13367 root       8    0   576K   444K wait     0:00  1.54%  0.15% make
  456 killing   96    0  5372K  1936K select   0:04  0.00%  0.00% sshd
 1962 root      96    0  2140K  1172K RUN      0:02  0.00%  0.00% top
  385 root      96    0  2628K  1644K select   0:01  0.00%  0.00% sshd
10489 root       8    0  4080K  3976K wait     0:01  0.00%  0.00% make
  661 killing   96    0  5372K  1960K select   0:01  0.00%  0.00% sshd
  390 root      96    0  3124K  1872K select   0:00  0.00%  0.00% sendmail
  618 root      20    0  1472K   964K pause    0:00  0.00%  0.00% csh
  233 root      96    0  1172K   664K select   0:00  0.00%  0.00% syslogd
  434 root       8    0  1236K   812K nanslp   0:00  0.00%  0.00% cron
  454 root       4    0  5380K  1872K sbwait   0:00  0.00%  0.00% sshd
  659 root       4    0  5380K  1920K sbwait   0:00  0.00%  0.00% sshd
  457 killing    8    0  1260K   808K wait     0:00  0.00%  0.00% bash
  665 root      20    0  1420K   884K pause    0:00  0.00%  0.00% csh
13371 root      -8    0  1096K   904K piperd   0:00  0.00%  0.00% as
  617 killing    8    0  1536K   984K wait     0:00  0.00%  0.00% su
  664 killing    8    0  1536K   984K wait     0:00  0.00%  0.00% su
12803 root       8    0   876K   436K wait     0:00  0.00%  0.00% sh
  327 root      96    0  1144K   604K select   0:00  0.00%  0.00% usbd
  662 killing    8    0  1256K   804K wait     0:00  0.00%  0.00% bash
12802 root       8    0   588K   464K wait     0:00  0.00%  0.00% make
  393 smmsp     20    0  2996K  1772K pause    0:00  0.00%  0.00% sendmail
  444 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  445 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  447 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  451 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  446 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  449 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  448 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
  450 root       5    0  1184K   736K ttyin    0:00  0.00%  0.00% getty
13369 root       8    0   316K   216K wait     0:00  0.00%  0.00% cc
13368 root       8    0   864K   420K wait     0:00  0.00%  0.00% sh
12801 root       8    0   860K   416K wait     0:00  0.00%  0.00% sh
  124 root      20    0   220K    76K pause    0:00  0.00%  0.00% adjkerntz

Sometimes the machine is busy according to the process total yet 100% idle
in the CPU states other times its 0% idle and the process totals add
to nothing.

>How-To-Repeat:
	run top while doing a kernel compile
>Fix:
	Unknown
>Release-Note:
>Audit-Trail:

From: Colin Percival <colin.percival@wadham.ox.ac.uk>
To: freebsd-gnats-submit@FreeBSD.org, killing@multiplay.co.uk
Cc:  
Subject: Re: bin/47235: top reports inaccurate cpu usage
Date: Sun, 09 Feb 2003 20:59:03 +0000

    I'm not sure this is a bug.  If a process starts and stops during the 
 interval between top's updates, its cpu usage will be reflected in the "CPU 
 states" header, but top won't list the process (because it isn't running 
 any longer).  This shows up most often while rebuilding the world or kernel 
 due to the large number of very short-lived processes which are spawned.
    This could be fixed, I suppose, by reading the accounting files, but I 
 don't think it's worth the added complexity.
 
 Colin Percival
 

From: "Steven Hartland" <killing@multiplay.co.uk>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Colin Percival" <colin.percival@wadham.ox.ac.uk>
Cc:  
Subject: Re: bin/47235: top reports inaccurate cpu usage
Date: Sun, 9 Feb 2003 21:21:49 -0000

 I've also notice a high discrepancy in on our game server which don't
 run short lived processes per say is there anyway I could investigate
 this further?
     
     Regards
     Steve
 ----- Original Message ----- 
 From: "Colin Percival" <colin.percival@wadham.ox.ac.uk>
 To: <freebsd-gnats-submit@FreeBSD.org>; <killing@multiplay.co.uk>
 Sent: 09 February 2003 20:59
 Subject: Re: bin/47235: top reports inaccurate cpu usage
 
 
 >    I'm not sure this is a bug.  If a process starts and stops during the 
 > interval between top's updates, its cpu usage will be reflected in the "CPU 
 > states" header, but top won't list the process (because it isn't running 
 > any longer).  This shows up most often while rebuilding the world or kernel 
 > due to the large number of very short-lived processes which are spawned.
 >    This could be fixed, I suppose, by reading the accounting files, but I 
 > don't think it's worth the added complexity.
 > 
 > Colin Percival
 > 
 
 ================================================
 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 
 
 In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
 or return the E.mail to postmaster@multiplay.co.uk.
 
 
State-Changed-From-To: open->feedback  
State-Changed-By: brucec 
State-Changed-When: Wed Sep 3 19:26:38 UTC 2008 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=47235 

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org, killing@multiplay.co.uk
Cc:  
Subject: Re: bin/47235: top(1) reports inaccurate cpu usage
Date: Wed, 03 Sep 2008 21:05:36 +0100

 Are you using the ULE scheduler on the machine?  The version of ULE in 
 FreeBSD 5 is known to produce results like this.
 
 -- 
 Bruce
State-Changed-From-To: feedback->closed 
State-Changed-By: edwin 
State-Changed-When: Thu Sep 25 15:47:53 UTC 2008 
State-Changed-Why:  
Like Colin says, with lots of short lived this is the expected result. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47235 
>Unformatted:
