Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Nov 2010 07:10:11 GMT
From:      Bruce Evans <brde@optusnet.com.au>
To:        freebsd-amd64@FreeBSD.org
Subject:   Re: amd64/152405: wrong user time is reported when CPU frequency throttled.
Message-ID:  <201011200710.oAK7ABCA038348@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/152405; it has been noted by GNATS.

From: Bruce Evans <brde@optusnet.com.au>
To: KOIE Hidetaka <koie@suri.co.jp>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org
Subject: Re: amd64/152405: wrong user time is reported when CPU frequency
 throttled.
Date: Sat, 20 Nov 2010 18:08:37 +1100 (EST)

 On Fri, 19 Nov 2010, KOIE Hidetaka wrote:
 
 >> Description:
 > when CPU frequency is throttled down, time command reports too low CPU usage like this:
 > 4.849u 0.000s 0:09.13 53.0%     9+5026k 0+0io 0pf+0w
 > 100% is expected, because the process is extreamly CPU-intensive.
 >
 > wall clock is precise.
 >
 > systat -vm 1 shows collect user time (25% in 4-core system).
 
 This is caused by broken scaling from "cputicks" (normally TSC cycles)
 to time (user+sys runtime).  Throttling is supposed to change the
 scaling, but at best the current scale factor is used for all cputicks,
 so the final runtime is wrong unless all of the accumulated ticks occurred
 while the current scale factor is correct.  Enforcement of monotonicity
 of the user and sys times individually avoids certain problems but makes
 the results even less related to actual times.
 
 The runtime should be the integral of the cputick count times the cputick
 frequency.  Integration is already used for other statistics so where and
 how to do it (in statclock() for curthread) is obvious in theory.  It
 should also be done whenever the cputick frequency is throttled or otherwise
 changed (e.g., by recalibration), or, as an optimization, not always done
 in statclock() but delayed until the frequency changes, or just delayed for
 a few seconds or minutes when the frequency doesn't change.  There are still
 problems with high frequency transient changes, undetected changes, and
 miscalibrated changes.
 
 P-state invariance for TSCs on newer x86's should limit this problem to older
 x86's and non-x86's.  IIRC, there is a sysctl to tell you if you have a
 P-state invariant TSC, but there afre no sysctls for telling what the
 cputicker is doing.  Timercounters are not related to any of this, except
 the TSC frequency is given by a timecounter sysctl, so you can see if if
 the system's idea of the TSC frequency tracks throttling correctly and then
 guess that the cputicker freqency is the TSC frequency.
 
 Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011200710.oAK7ABCA038348>