From owner-svn-src-head@FreeBSD.ORG Tue Jul 13 07:52:51 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BEAF106567C; Tue, 13 Jul 2010 07:52:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E57068FC17; Tue, 13 Jul 2010 07:52:47 +0000 (UTC) Received: by bwz12 with SMTP id 12so3545560bwz.13 for ; Tue, 13 Jul 2010 00:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=2hUu+KzZBQKkXmZ6HryA0O1g3PR3gA7DzF3L/DgatMc=; b=P5r3jpj07/U8bYBIIkXBpIcNMewiKvL53p50SFFKleBFbOKlxlYLLs+hXAxMr1eqfN yfbx6r6n4+GUelmx+zXz7f32AcQ+jD3Yrsim8jzxnV9dcMiUQTqyWrku4WQu+Tv0LJvw xDAtBA0rlypetjvjgGq/wz+eAeEomjosZxBJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HkbWcRatGHkURnnKxJRFTrJYHzKuN89ugumUgv/0QpyzkqfZmRwJp50pA00ToBUV2v SuejX62q8MkdBLqQcc0RG0mFJXgb5v5aKF5qRYtNLDI9ksvCUKXM88vEc45s0gKcGwoA rbTTbIjgmPFXdymoyO8JCUs0s++W3tjCEpsMA= Received: by 10.223.107.211 with SMTP id c19mr1556928fap.40.1279007566653; Tue, 13 Jul 2010 00:52:46 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 11sm690435fas.2.2010.07.13.00.52.45 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 00:52:46 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C3C1B4A.5070501@FreeBSD.org> Date: Tue, 13 Jul 2010 10:52:42 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Bruce Evans References: <201007111647.o6BGlk0O033551@svn.freebsd.org> <201007120813.19223.jhb@freebsd.org> <4C3B0F63.6000905@FreeBSD.org> <20100713162403.T62787@delplex.bde.org> In-Reply-To: <20100713162403.T62787@delplex.bde.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r209900 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 07:52:51 -0000 Bruce Evans wrote: > Fix for cputick calibration: > > % diff -c2 ./kern/kern_tc.c~ ./kern/kern_tc.c > % *** ./kern/kern_tc.c~ Thu Mar 20 01:05:27 2008 > % --- ./kern/kern_tc.c Thu Mar 20 01:05:29 2008 > % *************** > % *** 884,888 **** > % return; > % % ! getbinuptime(&t_this); > % c_this = cpu_ticks(); > % if (t_last.sec != 0) { > % --- 884,888 ---- > % return; > % % ! binuptime(&t_this); > % c_this = cpu_ticks(); > % if (t_last.sec != 0) { > > Minor fix for accuracy. > > % *************** > % *** 922,931 **** > % c_delta <<= 20; > % c_delta /= divi; > % ! if (c_delta > cpu_tick_frequency) { > % ! if (0 && bootverbose) > % ! printf("cpu_tick increased to %ju Hz\n", > % ! c_delta); > % ! cpu_tick_frequency = c_delta; > % ! } > % } > % } > % --- 922,930 ---- > % c_delta <<= 20; > % c_delta /= divi; > % ! if (0 && bootverbose) > % ! printf( > % ! "cpu_tick_frequency changed from %ju to %ju Hz\n", > % ! cpu_tick_frequency, c_delta); > % ! cpu_tick_frequency = c_delta; > % } > % } > > Variable frequencies have the interesting capability of varying in > both positive and negative directions. This fixes the case of > negative-going changes. Without this, the overflowing timecounter > cases caused cpu_tick_frequency to become huge (100's of times the > correct value), and it was clamped to the hugest value ever seen. The > way this mostly fixes the problem is that cpu_tick_frequency can be > off by a factor of 100, but only for 16 seconds or so until the next > calibration fixes it. I have no hardware to check, but I have feeling that calibration didn't work well also for older CPUs with variable TSC frequency, when frequency is decreasing. I see TSC timecounter frequency changed at tsc_freq_changed(), but set_cputicker() is not called there to adopt it, neither calibration can reduce it by itself. > I don't use this in the same kernels that have the fix for the > timecounters. An integrated fix would prevent recalibration until 16 > seconds after the timecounter has been restored. > > Setting cpu_tick_variable to 0 is an even simpler fix if the cputicker > is not very variable. Yes. In fact cputicker is invariable for the most of modern x86 CPUs. But it's frequency is not always precisely known. > Without this, normal frequency drift due to temperature changes caused > cpu_tick frequency to become larger than the correct value by a few > ppm. Again it was clamped to the largest value ever seen, but errors > of a few ppm are hard to see. -- Alexander Motin