From owner-freebsd-current@FreeBSD.ORG Fri Dec 3 17:26:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C80A1065675 for ; Fri, 3 Dec 2010 17:26:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DBA668FC19 for ; Fri, 3 Dec 2010 17:26:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA28927 for ; Fri, 03 Dec 2010 19:26:43 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CF92852.20705@freebsd.org> Date: Fri, 03 Dec 2010 19:26:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: non-invariant tsc and cputicker 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: Fri, 03 Dec 2010 17:26:45 -0000 FreeBSD uses cpu_ticks [function pointer] in a few places for a few things like process CPU time accounting. On x86 cpu_ticks always points to rdtsc. If TSC is not invariant that leads to incorrect accounting of "CPU ticks". The code pretends to try to handle changing cpufreq levels, but does that incorrectly. I think that we could use a selected timecounter instead of "raw" TSC if the latter is not invariant. In this case cpu_ticks calls would be slightly costlier, but always correct. The change is quite trivial: http://people.freebsd.org/~avg/tsc-cputicker.diff What do you think? P.S. it's probably a good idea to merge i386 and amd64 tsc.c files into a common x86 version, which would be the same as i386 version, which seems to be generic enough. -- Andriy Gapon