Debian Bug report logs - #222817
procps: top doesn't show CPU usage for Java

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: David Liontooth <liontooth@cogweb.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: procps: top doesn't show CPU usage for Java

Date: Wed, 03 Dec 2003 11:16:10 -0800

Package: procps
Version: 1:3.1.14-1
Severity: normal

top correctly displays memory utilization for Java, but incorrectly shows 
CPU utilization as none. This is true even when a Java application is
using most available CPU cycles and slowing everything else down.

Java VM version: Blackdown-1.4.1-01 with Java Media Framework

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux 2.6.0-test9 #2 Tue Oct 28 11:53:24 PST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages procps depends on:
ii  libc6                     2.3.2.ds1-10   GNU C Library: Shared libraries an
ii  libncurses5               5.3.20030719-3 Shared libraries for terminal hand

-- no debconf information

Message #10 received at 222817@bugs.debian.org (full text, mbox, reply):

From: csmall@enc.com.au (Craig Small)

To: David Liontooth <liontooth@cogweb.net>, 222817@bugs.debian.org

Subject: Re: Bug#222817: procps: top doesn't show CPU usage for Java

Date: Thu, 4 Dec 2003 10:27:36 +1100

On Wed, Dec 03, 2003 at 11:16:10AM -0800, David Liontooth wrote:
> top correctly displays memory utilization for Java, but incorrectly shows 
> CPU utilization as none. This is true even when a Java application is
> using most available CPU cycles and slowing everything else down.
> 
> Java VM version: Blackdown-1.4.1-01 with Java Media Framework

Can you show me the output of ps with this problem?
In addtion can you send me the /proc/NNN/stat and /proc/NNN/status files
for the pid with 0 CPU load.

What you have given me is not much to go on.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/   MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org 

Message #15 received at 222817@bugs.debian.org (full text, mbox, reply):

From: csmall@enc.com.au (Craig Small)

To: David Liontooth <liontooth@cogweb.net>

Cc: 222817@bugs.debian.org

Subject: Re: Bug#222817: procps: top doesn't show CPU usage for Java

Date: Thu, 4 Dec 2003 13:48:15 +1100

On Wed, Dec 03, 2003 at 05:59:17PM -0800, David Liontooth wrote:
> Here's top, showing java using 42% of memory and no CPU:
Thanks, brain said top, fingers typed ps but you worked out which one
I wanted anyhow.

> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 2427 david     25   0  690m 211m  58m S  0.0 42.1   0:01.05 java

OK, so no CPU load showing in top.

> cat /proc/2427/status
> Name:   java
> State:  S (sleeping)
The CPU % is only from the last refresh so if it is sleeping then it is
not running and eating CPU.

I'd say that's why it was 0%.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/   MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org 

Message #20 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Paul Martin <pm@debian.org>

To: 222817@bugs.debian.org

Subject: top getting CPU usage wrong for threaded programs

Date: Sat, 14 Feb 2004 19:49:49 +0000

I see this effect with ices2, running on a 2.6 kernel.

The first thread does very little, probably sitting waiting in
pthread_join(). The other threads do the real work, but aren't
accounted for in the top output.

-- 
Paul Martin <pm@debian.org>

Message #25 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Peter Chubb <peterc@gelato.unsw.edu.au>

To: 222817@bugs.debian.org

Subject: procps not accounting for all threads

Date: Wed, 25 Feb 2004 13:18:46 +1100

For what it's worth, neither top nor ps show the correct CPU times for
threaded programs when using NPTL on 2.6-series kernels.

The `CPU' output of ps and top seems to reflect only /proc/pid/stat,
not the sum of /proc/pid/task/tid/stat

For example:
$    ps ax | grep gigatest
 572 pts/0    S      0:00 ./build/net_test_benchmark/gigatest.bin

$    ps axH | grep gigatest
  572 pts/0    S      0:00 ./build/net_test_benchmark/gigatest.bin
  572 pts/0    S      0:00 ./build/net_test_benchmark/gigatest.bin
  572 pts/0    S      2:11 ./build/net_test_benchmark/gigatest.bin



I'm not sure whether the correct fix might not be to fix the kernel to
sum thread times into the process time displayed in /proc/pid/stat
whenever it's read.  Unfortunately, this'd have to be done under a
lock, making top and ps even more of a hog on large systems.

--
Dr Peter Chubb     http://www.gelato.unsw.edu.au  peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.

Message #30 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Jos van den Oever <jos.oever@gsf.de>

To: 222817@bugs.debian.org

Subject: procps not accounting for all threads

Date: Tue, 28 Sep 2004 16:26:07 +0200

An additional oddity with the /proc directory seems to be that not all threads 
are visible under /proc with 'ls /proc'. A given multithreaded application 
has its child threads as entries under /proc/$pid/task. For each of 
these /proc/$pid/task/$tid,  you can do a 'ls /proc/$tid' and get the data on 
that thread. The directory '/proc/$tid' is normally not listed with 
'ls /proc' (unless it's the parent itself).

I don't know if this is intended, but it is certainly illogical.

Message #35 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Samuel Thibault <samuel.thibault@ens-lyon.org>

To: Jos van den Oever <jos.oever@gsf.de>

Cc: 222817@bugs.debian.org

Subject: Re: procps not accounting for all threads

Date: Thu, 28 Oct 2004 12:06:45 +0200

Le mar 28 sep 2004 à 16:26:07 +0200, Jos van den Oever a tapoté sur son clavier :
> An additional oddity with the /proc directory seems to be that not all threads 
> are visible under /proc with 'ls /proc'. A given multithreaded application 
> has its child threads as entries under /proc/$pid/task. For each of 
> these /proc/$pid/task/$tid,  you can do a 'ls /proc/$tid' and get the data on 
> that thread. The directory '/proc/$tid' is normally not listed with 
> 'ls /proc' (unless it's the parent itself).
> 
> I don't know if this is intended, but it is certainly illogical.

This is intended and backward-compatible.

The proper way would be to only see pids in /proc, and not see tids. But
people probably got used to see tids in /proc, so that /proc/tid will
indeed work. But not listing seems will make people switch to not seeing
tids in /proc.

Regards,
Samuel Thibault

Message #40 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Jos van den Oever <jos.oever@gsf.de>

To: Samuel Thibault <samuel.thibault@ens-lyon.org>

Cc: 222817@bugs.debian.org

Subject: Re: procps not accounting for all threads

Date: Thu, 28 Oct 2004 12:18:28 +0200

On Thursday 28 October 2004 12:06, Samuel Thibault wrote:
> Le mar 28 sep 2004 à 16:26:07 +0200, Jos van den Oever a tapoté sur son 
clavier :
> > An additional oddity with the /proc directory seems to be that not all
> > threads are visible under /proc with 'ls /proc'. A given multithreaded
> > application has its child threads as entries under /proc/$pid/task. For
> > each of these /proc/$pid/task/$tid,  you can do a 'ls /proc/$tid' and get
> > the data on that thread. The directory '/proc/$tid' is normally not
> > listed with 'ls /proc' (unless it's the parent itself).
> >
> > I don't know if this is intended, but it is certainly illogical.
>
> This is intended and backward-compatible.
>
> The proper way would be to only see pids in /proc, and not see tids. But
> people probably got used to see tids in /proc, so that /proc/tid will
> indeed work. But not listing seems will make people switch to not seeing
> tids in /proc.

Thanks for your reply. Ok, so the code is meant to behave this way. That's 
silly, but up to the developers. Now that I know it, I can deal with it.
I don't understand your last sentence. Could you clarify it please?

Best regards, Jos van den Oever

Message #45 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Samuel Thibault <samuel.thibault@ens-lyon.org>

To: Jos van den Oever <jos.oever@gsf.de>

Cc: 222817@bugs.debian.org

Subject: Re: procps not accounting for all threads

Date: Thu, 28 Oct 2004 13:07:21 +0200

Le jeu 28 oct 2004 à 12:18:28 +0200, Jos van den Oever a tapoté sur son clavier :
> > But not listing seems will make people switch to not seeing
> > tids in /proc.
> 
> I don't understand your last sentence. Could you clarify it please?

Oops, mistype: replace "seems" by "them": not listing tids in /proc
shows people that /proc should only hold pids, and not tids. Actually,
as soon as I started some 2.6 kernel with nptl, I noticed that no tids
would show up in /proc. And I didn't even tried to look for /proc/tid
since it didn't show up. That means it works: people will get used to
not have tids in /proc, but rather in /proc/pid/task

Regards,
Samuel

Message #52 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Albert Cahalan <albert@users.sf.net>

To: 222817@bugs.debian.org, 278629@bugs.debian.org

Subject: fixed in the 2.6.10 kernel

Date: Mon, 01 Nov 2004 16:49:38 -0500

Upgrade to the current -mm tree (Andre Morton),
the current -bk tree (BitKeeper snapshot), or the
2.6.10 release when that is done.

Message #57 received at 222817@bugs.debian.org (full text, mbox, reply):

From: Jelle <jelle-debian-reportbug@foks.8m.com>

To: Debian Bug Tracking System <222817@bugs.debian.org>

Subject: procps: Maybe caused by #278629

Date: Fri, 04 Mar 2005 19:07:00 -0500

Package: procps
Version: 1:3.2.5-1
Followup-For: Bug #222817

Wouldn't that be cause by what is described in bug "#278629: procps: top doesn't handle 2.6 threads %cpu correctly" ?

Jelle.



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-athlon
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages procps depends on:
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libncurses5                 5.4-4        Shared libraries for terminal hand

-- no debconf information

Message #64 received at 222817@bugs.debian.org (full text, mbox, reply):

From: David Liontooth <liontooth@cogweb.net>

To: Debian Bug Tracking System <222817@bugs.debian.org>

Subject: procps: Please close this bug

Date: Sun, 20 Nov 2005 20:13:24 -0800

Package: procps
Version: 1:3.2.6-2
Followup-For: Bug #222817


I cannot confirm this bug anymore and request it be closed (I opened it).

Dave


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages procps depends on:
ii  libc6                         2.3.5-7    GNU C Library: Shared libraries an
ii  libncurses5                   5.5-1      Shared libraries for terminal hand

Versions of packages procps recommends:
ii  psmisc                        21.8-1     Utilities that use the proc filesy

-- no debconf information

Message #69 received at 222817-done@bugs.debian.org (full text, mbox, reply):

From: csmall@enc.com.au (Craig Small)

To: David Liontooth <liontooth@cogweb.net>, 222817-done@bugs.debian.org

Subject: Re: Bug#222817: procps: Please close this bug

Date: Tue, 3 Jan 2006 23:44:16 +1100

On Sun, Nov 20, 2005 at 08:13:24PM -0800, David Liontooth wrote:
> I cannot confirm this bug anymore and request it be closed (I opened it).

Thanks! Closed the bug.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/   MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

Send a report that this bug log contains spam.