Date: Mon, 6 Dec 2010 12:42:59 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker Message-ID: <201012061243.08577.jkim@FreeBSD.org> In-Reply-To: <4CFA220A.30405@freebsd.org> References: <4CF92852.20705@freebsd.org> <201012031938.12684.jkim@FreeBSD.org> <4CFA220A.30405@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012061243.08577.jkim>