Bug 4056 - anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Summary: anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.0
Hardware: alpha Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Keywords:
: 3838 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-07-15 16:17 UTC by Jeff Johnson
Modified: 2008-08-01 16:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jeff Johnson 1999-07-15 16:17:20 UTC
Here's the output, program attached
deathstar.support.redhat.com

Linux version 2.2.5-24smp (root@jetson.devel.redhat.com)
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2
release))
#1 SMP Fri Jul 9 16:00:42 EDT 1999

glibc-2.1.1-7 :

gettimeofday() reports 9.1871 seconds real time elapsed
clock() reports 73435216 cpu time or 73.4352 seconds
times() reports 9403 clock ticks or 75240 user and 1 sys
itimer reports 9.1831 real time, 73.4759 user, and 9.1850
sys+user

glibc-2.1.2-1 :

gettimeofday() reports 9.1808 seconds real time elapsed
clock() reports 73395200 cpu time or 73.3952 seconds
times() reports 9397 clock ticks or 75200 user and 0 sys
itimer reports 9.1772 real time, 73.4368 user, and 9.1792
sys+user

Comment 1 Jeff Johnson 1999-07-15 16:24:59 UTC
Note: this problem is present in glibc-2.1.2 (from Ken Crandall).

Comment 2 Jeff Johnson 1999-07-23 09:28:59 UTC
*** Bug 3838 has been marked as a duplicate of this bug. ***


There seems to be a problem with process CPU time display on
Linux Alpha systems.  The process CPU
time increments MUCH faster than wall clock time.  The CPU
time seems to be about 8 to 10 times faster
than wall clock time.  You can see this with either a "w"
display or a "top" display.  For example:

[hibbert@spe85 ~]$ w
Unknown HZ value! (2048) Assume 1024.
  3:47pm  up 38 min,  5 users,  load average: 1.85, 1.27,
0.73
USER     TTY      FROM              LOGIN@   IDLE   JCPU
PCPU  WHAT
root     tty1     -                 3:09pm  0.00s  1.02s
0.78s  talk cnbc
root     tty2     -                 3:39pm  3:29   0.27s
0.14s  -bash
cnbc     pts/0    VIM.BOLTZ.CS.CMU  3:29pm  0.00s  7.03s
0.55s  talk root@spe85
hibbert  pts/1    tnt1-159.mtco.co  3:44pm  1:55  15:12
15:11   ./setiathome
hibbert  pts/2    tnt1-159.mtco.co  3:45pm  0.00s  0.43s
0.06s  w

Note that the first hibbert process has been logged in for
only about 2 minutes, yet has used 15 minutes of
CPU time.  I know Alpha's are fast, but I didn't think they
could bend time!   This bug does not appear to
be a problem for the Proliant Intel based system.

I have been trying to track down this problem.  I suspect
there is a system function that convers CPU ticks
to seconds that is assuming the Alpha is using the common PC
interval clock rate of 100/second rather than
the 1K/second rate that most Alpha's actually use.   I have
not been able to locate the source code for the
"w" program to see what function calls it uses to convert
the time.

Comment 3 Jeff Johnson 1999-07-23 09:32:59 UTC
This appears to be a 2.2.5smp kernel bug: the user time returned
by the times system call seems to be incorrect.

Comment 4 Cristian Gafton 1999-07-28 07:58:59 UTC
This should be fixed in a later release of the linux kernel, which I
am putting out now.

There is a kernel-2.2.10-3 now in the tree - can anybody tell me if
the problem is still there so that I can get rth on board?


Note You need to log in before you can comment on or make changes to this bug.