From owner-svn-src-head@FreeBSD.ORG Tue Jul 13 12:47:47 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 CA783106566C; Tue, 13 Jul 2010 12:47:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBBE8FC1D; Tue, 13 Jul 2010 12:47:46 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6DClhwI017697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 22:47:44 +1000 Date: Tue, 13 Jul 2010 22:47:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Motin In-Reply-To: <4C3C1B4A.5070501@FreeBSD.org> Message-ID: <20100713222551.K62994@delplex.bde.org> References: <201007111647.o6BGlk0O033551@svn.freebsd.org> <201007120813.19223.jhb@freebsd.org> <4C3B0F63.6000905@FreeBSD.org> <20100713162403.T62787@delplex.bde.org> <4C3C1B4A.5070501@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans 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 12:47:47 -0000 On Tue, 13 Jul 2010, Alexander Motin wrote: > Bruce Evans wrote: >> Fix for cputick calibration: >> ... >> Variable frequencies have the interesting capability of varying in >> both positive and negative directions. This fixes the case of >> negative-going changes. ... > > 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. It is only called from init_TSC() and tsc_levels_changed(). I don't really understand tsc_xxx_change*(). It's interesting that the call in tsc_levels_changed() passes `max_freq' as the frequency. Is the calibrator expected to reduce from a maximum frequency to a much smaller throttled frequency? But it can only go the other way without my change. >> 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. When it is invariable, it is easy to determine precisely (just wait long enough to find the average to the desired accuracy (this is only seconds for 1 ppm even with a slow timecounter like ACPI-fast as a reference). Try ~bde/tsccalib/tsccalib.c on a FreeBSD cluster machine. This requires all the CPUs to be in sync since it doesn't know how to pin the thread to a CPU. Bruce