From owner-freebsd-current@FreeBSD.ORG Tue Feb 27 18:16:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB98E16A400 for ; Tue, 27 Feb 2007 18:16:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id B015E13C4D0 for ; Tue, 27 Feb 2007 18:16:46 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1RIGj19082712; Tue, 27 Feb 2007 12:16:45 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45E47590.407@freebsd.org> Date: Tue, 27 Feb 2007 12:16:48 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Poul-Henning Kamp References: <39154.1172597663@critter.freebsd.dk> In-Reply-To: <39154.1172597663@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2665/Tue Feb 27 10:26:03 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: too short/too long (sys/kern_tc.c) 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: Tue, 27 Feb 2007 18:16:49 -0000 On 02/27/07 11:34, Poul-Henning Kamp wrote: > In message <45E43984.4020809@freebsd.org>, Eric Anderson writes: > >> When I boot a -CURRENT box with boot verbose enabled inside qemu, I see >> one of these messages about every second: >> >> 15.f68c5ee76faebe10 too short >> 16.0f822e13092c5580 too long > > This is a symptom of lousy scheduling or even worse interrupt > latency. > > In your case +0.060/-0.036 sec per 16 seconds or a couple of percent > in relative terms. (The printf is counter intuitive: the integer > part is in decimal). > > I will readily admit that the 1/256 of a second limit is chosen > pretty much at random, but with an eye to allowing a division > by 16 to get close the right result. > > All of this futz is of course to avoid floating point in the kernel. > > As to why: My main suspect would be the BIOS/ACPI/SMM code, with > a keen eye to the new interrupt filtering code and what it might > do to the clock/scheduling interrupts. > Thanks for the reply and info. It turns out that enabling acpi in the kernel makes it go away, so I'm happy. I'm not certain if anyone should care much about it, besides the fact that it might be pointing to something else more important. Are these at all related to the calcru messages people have been seeing? I have to admit, I haven't looked much in the archives on the calcru history. I'm mostly asking for the others who have responded to me privately after sending this message. Eric