Date: Tue, 21 Jun 2011 12:11:58 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r222866 - head/sys/x86/x86 Message-ID: <201106211212.03140.jkim@FreeBSD.org> In-Reply-To: <201106211156.38396.jhb@freebsd.org> References: <201106081938.p58JcWuB044252@svn.freebsd.org> <201106211149.02280.jkim@FreeBSD.org> <201106211156.38396.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 21 June 2011 11:56 am, John Baldwin wrote: > On Tuesday, June 21, 2011 11:48:55 am Jung-uk Kim wrote: > > On Tuesday 21 June 2011 09:10 am, John Baldwin wrote: > > > On Monday, June 20, 2011 7:41:00 pm Jung-uk Kim wrote: > > > > My questions to you: > > > > > > > > a) Why do we care TSC timecounter when it is not invariant > > > > where we *know* it is unusable and set to negative quality? > > > > > > What if the user knows they will not enable CPU throttling so > > > for them the TSC is safe? In that case, TSC is a more > > > efficient timecounter and if the user constrains the system to > > > make the TSC safe we should let them use it. > > > > In that case, it must be a UP system, the quality is still 800, > > and TSC value won't be shifted. > > > > My question was specific to SMP cases. Sorry, I didn't make that > > clear. > > What if the user has an SMP system where the TSCs are in sync but > it's older so it doesn't set the TSC invariant bit set in cpuid. > Are we now forbidding that user from using the TSC? We do not forbid it but we cannot increase the quality because we don't compensate drift. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106211212.03140.jkim>