From owner-freebsd-current@FreeBSD.ORG Sat Dec 4 01:42:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 013A91065670; Sat, 4 Dec 2010 01:42:16 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4CF99C61.6020303@freebsd.org> Date: Sat, 04 Dec 2010 09:41:53 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012031305.53750.jkim@FreeBSD.org> <4CF93395.3060601@freebsd.org> <201012031504.02532.jkim@FreeBSD.org> In-Reply-To: <201012031504.02532.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: 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: Sat, 04 Dec 2010 01:42:17 -0000 Jung-uk Kim wrote: > On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote: > >> on 03/12/2010 20:05 Jung-uk Kim said the following: >> >>> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote: >>> >>>> 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. >>>> >>> Arg... Probably it is my fault. :-( >>> >>> >>>> 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? >>>> >>> Why don't we just fix it properly? >>> >> Patch? :-) >> > > Attached. > > >> It seems that it is not too trivial to do and is prone to error >> accumulation given how the ticks are added up. >> Besides, why using a timecounter would not be a proper fix? >> > > Well, it is not that simple, unfortunately. Because init_TSC() is > called very early, your patch will select dummy timecounter as a CPU > ticker if my memory serves. It is very hard to implement right on > x86 arch. :-( > > So many years, they can not make a simple counter work correctly, I have seen so many failed technologies in the tech world, and will still happen frequently. :-)