From owner-freebsd-current@FreeBSD.ORG Tue Feb 27 17:34:26 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 3BD6616A400 for ; Tue, 27 Feb 2007 17:34:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D63EA13C442 for ; Tue, 27 Feb 2007 17:34:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 6C2E317462; Tue, 27 Feb 2007 17:34:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1RHYNuM039155; Tue, 27 Feb 2007 17:34:24 GMT (envelope-from phk@critter.freebsd.dk) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Feb 2007 08:00:36 CST." <45E43984.4020809@freebsd.org> Date: Tue, 27 Feb 2007 17:34:23 +0000 Message-ID: <39154.1172597663@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 17:34:26 -0000 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.