From owner-freebsd-current@FreeBSD.ORG  Mon Dec  6 17:43:22 2010
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 739801065673;
	Mon,  6 Dec 2010 17:43:21 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
From: Jung-uk Kim <jkim@FreeBSD.org>
To: Andriy Gapon <avg@freebsd.org>
Date: Mon, 6 Dec 2010 12:42:59 -0500
User-Agent: KMail/1.6.2
References: <4CF92852.20705@freebsd.org> <201012031938.12684.jkim@FreeBSD.org>
	<4CFA220A.30405@freebsd.org>
In-Reply-To: <4CFA220A.30405@freebsd.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201012061243.08577.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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 17:43:22 -0000

On Saturday 04 December 2010 06:12 am, Andriy Gapon wrote:
> on 04/12/2010 02:38 Jung-uk Kim said the following:
> > If my understanding is correct, your patch uses the dummy
> > timecounter until a real timecounter is chosen.
>
> Perhaps this is one way to look at it.
> But I look at it differently - the patch makes cpu_ticks refer to
> tc_cpu_ticks. That is, it make _the_ timecounter be used for cpu
> ticks.
> Exact timecounter backend is not important to me.
>
> > When a real timecounter is set,
> > tc_cpu_ticks() changes the frequency naturally.  How are you
> > going to solve this problem?
>
> Do we really care about cpu ticks accounting that early in the
> boot?
>
> >  What should we do when a user set a new
> > timecounter hardware via "sysctl kern.timecounter.hardware"?
>
> User can expect some instability (*if any*) when he does such a
> significant system reconfiguration.
> I put "if any", because I think that tc_cpu_ticks() should handle
> this. The same way as you don't see time returned by e.g.
> nanotime() going crazy at that moment.
>
> > I don't
> > think it is any better than current code.  Am I missing
> > something? :-(
>
> I think that it is much better.
> Handling of P-state changes for non-invariant TSC is just
> incorrect. kern.timecounter.hardware is not going to be changed as
> frequently as P-states, if ever.

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.

Jung-uk Kim