Date: Wed, 22 Oct 2008 14:29:47 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: "Attilio Rao" <attilio@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r184108 - head/sys/i386/i386 Message-ID: <200810221429.51834.jkim@FreeBSD.org> In-Reply-To: <3bbf2fe10810220853r34256b59y1fe57f49eca2014@mail.gmail.com> References: <200810210431.m9L4V7Pb088978@svn.freebsd.org> <200810211605.46927.jkim@FreeBSD.org> <3bbf2fe10810220853r34256b59y1fe57f49eca2014@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 22 October 2008 11:53 am, Attilio Rao wrote: > 2008/10/21, Jung-uk Kim <jkim@freebsd.org>: > > On Tuesday 21 October 2008 06:07 am, Attilio Rao wrote: > > > Something we could do with this is adding a "quirk" table of > > > TSC arch dependant known to be working (based on cpu_model and > > > such) and use that table in order to replace tsc_smp. > > > > Please note the invariant_tsc and smp_tsc are different. If we > > go with the route, we need two quirk tables. :-( > > It doesn't matter. > I think it is silly we have different quirks flag states for TSC. > We should just having a table assuming that the TSC is safe to use > in SMP environments and gets rid of any other flag (in this case, > for amd64 based machine, the logic could, for example, check if the > CPU is P state invariant and assume it is safe, etc.) Yes, it does matter as TSC is not just for timecounter and it can be used independently. For example, if a thread is bound to a CPU, it can provide the fastest AND safest timer. Besides, the whole point was not to modify TSC freq. if it is independent from CPU freq. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810221429.51834.jkim>