From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:40:34 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 089A21065679; Mon, 6 Dec 2010 18:40:34 +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 F24FC8FC1F; Mon, 6 Dec 2010 18:40:32 +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 UAA13938; Mon, 06 Dec 2010 20:40:31 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD2E1E.2080604@freebsd.org> Date: Mon, 06 Dec 2010 20:40:30 +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: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> <4CFD2441.5090408@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> In-Reply-To: <201012061334.22475.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:40:34 -0000 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=155444 >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=155534 >>> >>> 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! >> 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? -- Andriy Gapon