Date: Sun, 12 Feb 2006 23:34:38 +0300 (MSK) From: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>, freebsd-current@freebsd.org Subject: Re: calcru: runtime went backwards Message-ID: <20060212225911.M598@free.home.local> In-Reply-To: <29218.1139772457@critter.freebsd.dk> References: <29218.1139772457@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> With -CURRENT up to 2006-02-12 06:57:41 UTC (last commit by scottl) >> I still can see some calcru messages: > > Right, but these have much smaller deltas than the other ones you saw. > >> calcru: runtime went backwards from 3508844 usec to 3508842 usec for pid 28 (pagezero) > > My theory currently is that these are side effects of the cputick > calibration code: If the cputick rate gets measured to be a bit higher, > the next calculation will result in slightly lower numbers for the > cpu utilization in microseconds and the warning will fire. > > This will be particularly easy to trigger on machines with power > management on (laptops mostly). > > My current inclination is to simply not issue this warning if the > cpu_tick is marked as "variable". > > The other side of this is that I've been looking at having the > ACPI power management code announce the maximum speed of the TSC > to the cputick code, that would make such machines "fixed frequency" > cpu_tick machines from the start and even if enabled, this warning > should not issue in that case. I have CPU (AMD K6) with TSC, but my motherboard (ASUS TX97) does not support ACPI. This combination can also be treated as a "fixed frequency" machine. Yuriy.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060212225911.M598>