From owner-freebsd-current@FreeBSD.ORG Sun Feb 12 20:35:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2A616A420 for ; Sun, 12 Feb 2006 20:35:46 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 891F843D55 for ; Sun, 12 Feb 2006 20:35:44 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from dialup-chibis.gfk.ru by mx.gfk.ru (MDaemon.PRO.v8.1.4.R) with ESMTP id md50000048567.msg for ; Sun, 12 Feb 2006 23:34:36 +0300 Date: Sun, 12 Feb 2006 23:34:38 +0300 (MSK) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: Poul-Henning Kamp In-Reply-To: <29218.1139772457@critter.freebsd.dk> Message-ID: <20060212225911.M598@free.home.local> References: <29218.1139772457@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Processed: mx.gfk.ru, Sun, 12 Feb 2006 23:34:36 +0300 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.6.45 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx.gfk.ru, Sun, 12 Feb 2006 23:34:37 +0300 Cc: Yuriy Tsibizov , freebsd-current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 20:35:46 -0000 >> 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.