From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:34:36 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 21E3B106566B; Mon, 6 Dec 2010 18:34:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 13:34:19 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> <4CFD2441.5090408@freebsd.org> In-Reply-To: <4CFD2441.5090408@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061334.22475.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 18:34:36 -0000 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. > 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. > So, I don't think that I propose a dramatic change. Shrug... Still I want to see some evidence. Jung-uk Kim