svn commit: r184108 - head/sys/i386/i386

[Jung-uk Kim]

On Tuesday 21 October 2008 04:05 pm, Jung-uk Kim wrote:
> 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. :-(
>
> BTW, Linux is using TSC now when the P-state invariant TSC bit is
> set by BIOS for AMD CPUs:
>
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246251.
>html
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246769.
>html
>
> "After a lot of discussions with AMD it turns out that TSC on
> Fam10h CPUs is synchronized when the CONSTANT_TSC cpuid bit is set.
> Or rather that if there are ever systems where that is not true it
> would be their BIOS' task to disable the bit."
>
> If this is statement is true, then we should do:
>
> 	if (amd_pminfo & AMDPM_TSC_INVARIANT)
> 		smp_tsc = 1;

I don't know if the above is true but "AMD Family 10h Processor BKDG" 
says the following on page 109:

"Timers associated with different CPU cores in the same processor 
increment at the same rate. Timers associated with different CPU 
cores in different processors increment at slightly different rates 
if (1) they are located on different nodes and (2) CLKIN for these 
nodes is derived from different, non-synchronized oscillator 
sources."

Now the problem is to detect the case reliably AND to find the diffs 
between TSCs.  Once we get the information, we can use RDTSCP 
instruction to adjust it by the diff table.  But I guess it is 
hard. :-(

> Also, I think we can safely assume:
>
> 	if (AMD64_FAMILY(cpu_id) >= 0x10)
> 		tsc_is_invariant = 1;

I think this is always correct by the document.  I will change the 
code soon.

> Does anyone know whether these are correct assumptions?

Anyone?

Jung-uk Kim