Bug 4056

Summary:	anomalous user time from clock(3)/times(3)/setitimer(3) on SMP alpha
Product:	[Retired] Red Hat Linux	Reporter:	Jeff Johnson <jbj>
Component:	kernel	Assignee:	Cristian Gafton <gafton>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	gafton, ken.crandall, michael.waite
Target Milestone:	---
Target Release:	---
Hardware:	alpha
OS:	Linux
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:

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.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?