From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:01:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1D92C10656B7; Mon, 6 Dec 2010 19:01:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 14:01:15 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> <4CFD2E1E.2080604@freebsd.org> In-Reply-To: <4CFD2E1E.2080604@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061401.17904.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org 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: Mon, 06 Dec 2010 19:01:31 -0000 On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote: > on 06/12/2010 20:34 Jung-uk Kim said the following: > > On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: > >> on 06/12/2010 19:42 Jung-uk Kim said the following: > >>> Sigh... Please see the history of calcru() in > >>> sys/kern/kern_resource.c. Most important ones are: > >>> > >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15544 > >>>4 > >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15553 > >>>4 > >>> > >>> Basically, we chose efficiency over accuracy and you are > >>> suggesting going backwards. > >> > >> Well, I guess that it depends. > >> > >> Looking at r155444 - the time is still going to be accounted in > >> ticks (but timecounter ticks). BTW, I think that this quote > >> says something: "On more modern hardware no change in > >> performance is seen." and that was ~5 years ago. > > > > "On slower machines, the avoided multiplications to normalize > > timestams at every context switch, comes out as a 5-7% better > > score on the unixbench/context1 microbenchmark. On more modern > > hardware no change in performance is seen." > > > > His performance measurement was done for "the avoided > > multiplications to normalize timestamps at every context switch", > > not for "change CPU ticker from tc_cpu_ticks() to cpu_ticks()", > > which actually happened in r155534 later. > > Right. I was just pointing out a fact. > That change is not going to get undone anyways. > > >> Looking at r155534 - the only change that is going to get undone > >> is using TSC for the accounting ticks, and that is only for > >> machines with non-invariant TSC. And I think that all > >> sufficiently modern machines have invariant TSC and, in Intel's > >> words, that's an architectural path going forward. > > > > I understand that. However, it is not clear to me why you want > > to pessimize performance of old hardware. If you can convince me > > old hardware with slow timecounter hardware (e.g., i8254) does > > not hurt too much, maybe it's okay. > > Well, weighing totally bogus stats vs slight stats collection > pessimization, I have a new proposal - why we don't just hardcode > some stats values? That would give that code unbeatable > performance! :-) Don't get me wrong, I generally agree with you *iff* it does not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. > >> So, I don't think that I propose a dramatic change. > > > > Shrug... Still I want to see some evidence. > > Evidence of what? > That nothing is going to be changed for new hardware? > Or that older hardware won't be slowed down to a crawl? The latter, kinda. Jung-uk Kim