Date: Tue, 13 Jul 2010 22:47:43 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r209900 - head/sys/kern Message-ID: <20100713222551.K62994@delplex.bde.org> In-Reply-To: <4C3C1B4A.5070501@FreeBSD.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100713222551.K62994>