Date: Tue, 21 Jun 2011 11:56:38 -0400 From: John Baldwin <jhb@freebsd.org> To: "Jung-uk Kim" <jkim@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: <201106211156.38396.jhb@freebsd.org> In-Reply-To: <201106211149.02280.jkim@FreeBSD.org> References: <201106081938.p58JcWuB044252@svn.freebsd.org> <201106210910.25697.jhb@freebsd.org> <201106211149.02280.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106211156.38396.jhb>