Date: Sat, 20 Nov 2010 18:08:37 +1100 (EST) 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. Message-ID: <20101120173648.M1340@besplex.bde.org> In-Reply-To: <201011191235.oAJCZHVW062120@www.freebsd.org> References: <201011191235.oAJCZHVW062120@www.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?20101120173648.M1340>