[lttv.git] / ltt / branches / poly / doc / developer / tsc.txt


*************************************************************
AMD
http://lkml.org/lkml/2005/11/4/173
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
http://developer.amd.com/article_print.jsp?id=92 (RH)

[7] AMD's 7th  generation  processors return  a CPUID  base
    family value of '7'. These include AMD Athlon, AthlonXP,
    AthlonMP, and Duron.

[8] AMD's  8th generation  processors  return an  effective
    CPUID family of '0x0F'. These include AMD Opteron, 
    Athlon64, and Turion.


before 7th gen : ok
7th gen:
  P-state (performance state) change
    sol : disable powernow
  STPCLK-Throttling (temperature) : only done on UP, ok
8th gen :
  P-state change
    dual-core : locked-step
    SMP : may drift
    sol : disable powernow
  SMP, dual core : C1-clock ramping (halt) (power state : C-state)
    sol : idle=poll or disable C1-ramping
  STPCLK-Throttling (temperature) :
    single processor dual-core ok
    SMP : NOT ok (rare)


Until TSC  becomes invariant, AMD  recommends that operating
system  developers  avoid TSC  as  a  fast  timer source  on
affected systems. (AMD  recommends that the operating system
should  favor these  time sources  in a  prioritized manner:
HPET first,  then ACPI PM  Timer, then PIT.)   The following
pseudo-code shows one way of determining when to use TSC:

 use_AMD_TSC() { // returns TRUE if ok to use TSC
   if (CPUID.base_family < 0xf) {
             // TSC drift doesn't exist on 7th Gen or less
             // However, OS still needs to consider effects
             // of P-state changes on TSC
             return TRUE;
   } else if (CPUID.AdvPowerMgmtInfo.TscInvariant) {
             // Invariant TSC on 8th Gen or newer, use it
             // (assume all cores have invariant TSC)
             return TRUE;
   } else if ((number_processors == 1)&&(number_cores == 1)){
             // OK to use TSC on uni-processor-uni-core
             // However, OS still needs to consider effects
             // of P-state changes on TSC
             return TRUE;
   } else if ( (number_processors == 1) && 
               (CPUID.effective_family == 0x0f) &&
               !C1_ramp_8gen                       ){
             // Use TSC on 8th Gen uni-proc with C1_ramp off 
             // However, OS still needs to consider effects
             // of P-state changes on TSC
             return TRUE;
   } else {
             return FALSE;
   }
 }
 C1_ramp_8gen() {
    // Check if C1-Clock ramping enabled in  PMM7.CpuLowPwrEnh
    // On 8th-Generation cores only. Assume BIOS has setup
    // all Northbridges equivalently.
    return (1 & read_pci_byte(bus=0,dev=0x18,fcn=3,offset=0x87));
 }


When  an operating  system can  not avoid  using TSC  in the
short-term,  the  operating   system  will  need  to  either
re-synchronize the TSC of  the halted core when exiting halt
or disable C1-clock  ramping.  The pseudo-code for disabling
C1-clock ramping follows:

 if ( !use_AMD_TSC() && 
      (CPUID.effective_family == 0x0f) &&
      C1_ramp_8gen()                       ){
    for (i=0; i < number_processors; ++i){
       // Do for all NorthBridges in platform
       tmp = read_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87);
       tmp &= 0xFC;    // clears pmm7[1:0]
       write_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87,tmp)
      }
 }


Future TSC Directions and Solutions
===================================
Future AMD processors will provide a TSC that is P-state and
C-State invariant and unaffected by STPCLK-throttling.  This
will make  the TSC immune  to drift.  Because using  the TSC
for  fast  timer APIs  is  a  desirable  feature that  helps
performance,  AMD  has  defined  a CPUID  feature  bit  that
software   can   test   to   determine   if   the   TSC   is
invariant. Issuing a CPUID instruction with an %eax register
value of  0x8000_0007, on a  processor whose base  family is
0xF, returns "Advanced  Power Management Information" in the
%eax, %ebx, %ecx,  and %edx registers.  Bit 8  of the return
%edx is  the "TscInvariant" feature  flag which is  set when
TSC is P-state, C-state, and STPCLK-throttling invariant; it
is clear otherwise.

The  rate of the  invariant TSC  is implementation-dependent
and  will likely  *not* be  the frequency  of  the processor
core; however,  its period should be short  enough such that
it is  not possible for two  back-to-back rdtsc instructions
to  return the  same  value.  Software  which  is trying  to
measure  actual  processor  frequency  or  cycle-performance
should  use Performance  Event 76h,  CPU Clocks  not Halted,
rather than the TSC to count CPU cycles.


*************************************************************
Intel

Pentium M
  family [06H], models [09H, 0DH]
  SOL : disable speedstep
Pentium 4 processors, Intel Xeon
  family [0FH], models [00H, 01H, or 02H]
  SOL : disable speedstep

Other : ok

http://download.intel.com/design/Xeon/specupdt/30675712.pdf
http://forum.rightmark.org/post.cgi?id=print:6:269&user=%20Dmitri%20Besedin&color=1
http://bochs.sourceforge.net/techspec/24161821.pdf cpuid

cpuz
AFAIK this problem only concerns Prescott CPUs, but I bet future production will
also use the same rule.

Well, from what Intel states in one of their docs (Intel(R) Pentium(R) M
Processor on 90 nm Process with 2-MB L2 Cache, Specification Update, Document
No. 302209-010 (http://www.intel.com/design/mobile/specupdt/302209.htm) ), your
supposition is true:


Article V. For Pentium M processors (family [06H], models [09H, 0DH]); for
Pentium 4 processors, Intel Xeon processors (family [0FH], models [00H, 01H, or
02H]); and for P6 family processors: the timestamp counter increments with every
internal processor clock cycle. The internal processor clock cycle is determined
by the current core-clock to bus-clock ratio. Intel(R) SpeedStep(R) technology
transitions may also impact the processor clock.

Article VI. For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and higher]): the time-stamp counter increments at a constant rate.
That rate may be set by the maximum core-clock to bus-clock ratio of the
processor or may be set by the frequency at which the processor is booted. The
specific processor configuration determines the behavior. Constant TSC behavior
ensures that the duration of each clock tick is uniform and supports the use of
the TSC as a wall clock timer even if the processor core changes frequency. This
is the architectural behavior moving forward.


It's a pity they call this sucking TSC behavior an "architectural behavior
moving forward"


*************************************************************
HPET

http://www.intel.com/hardwaredesign/hpetspec_1.pdf
Commit	Line	Data
fe5ba1d0	1
	2	*************************************************************
	3	AMD
	4	http://lkml.org/lkml/2005/11/4/173
	5	http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
	6	http://developer.amd.com/article_print.jsp?id=92 (RH)
	7
	8	[7] AMD's 7th generation processors return a CPUID base
	9	family value of '7'. These include AMD Athlon, AthlonXP,
	10	AthlonMP, and Duron.
	11
	12	[8] AMD's 8th generation processors return an effective
	13	CPUID family of '0x0F'. These include AMD Opteron,
	14	Athlon64, and Turion.
	15
	16
	17	before 7th gen : ok
	18	7th gen:
	19	P-state (performance state) change
	20	sol : disable powernow
	21	STPCLK-Throttling (temperature) : only done on UP, ok
	22	8th gen :
	23	P-state change
	24	dual-core : locked-step
	25	SMP : may drift
	26	sol : disable powernow
	27	SMP, dual core : C1-clock ramping (halt) (power state : C-state)
	28	sol : idle=poll or disable C1-ramping
	29	STPCLK-Throttling (temperature) :
	30	single processor dual-core ok
	31	SMP : NOT ok (rare)
	32
	33
	34	Until TSC becomes invariant, AMD recommends that operating
	35	system developers avoid TSC as a fast timer source on
	36	affected systems. (AMD recommends that the operating system
	37	should favor these time sources in a prioritized manner:
	38	HPET first, then ACPI PM Timer, then PIT.) The following
	39	pseudo-code shows one way of determining when to use TSC:
	40
	41	use_AMD_TSC() { // returns TRUE if ok to use TSC
	42	if (CPUID.base_family < 0xf) {
	43	// TSC drift doesn't exist on 7th Gen or less
	44	// However, OS still needs to consider effects
	45	// of P-state changes on TSC
	46	return TRUE;
	47	} else if (CPUID.AdvPowerMgmtInfo.TscInvariant) {
	48	// Invariant TSC on 8th Gen or newer, use it
	49	// (assume all cores have invariant TSC)
	50	return TRUE;
	51	} else if ((number_processors == 1)&&(number_cores == 1)){
	52	// OK to use TSC on uni-processor-uni-core
	53	// However, OS still needs to consider effects
	54	// of P-state changes on TSC
	55	return TRUE;
	56	} else if ( (number_processors == 1) &&
	57	(CPUID.effective_family == 0x0f) &&
	58	!C1_ramp_8gen ){
	59	// Use TSC on 8th Gen uni-proc with C1_ramp off
	60	// However, OS still needs to consider effects
	61	// of P-state changes on TSC
	62	return TRUE;
	63	} else {
	64	return FALSE;
65	}
66	}
67	C1_ramp_8gen() {
68	// Check if C1-Clock ramping enabled in PMM7.CpuLowPwrEnh
69	// On 8th-Generation cores only. Assume BIOS has setup
70	// all Northbridges equivalently.
71	return (1 & read_pci_byte(bus=0,dev=0x18,fcn=3,offset=0x87));
72	}
73
74
75	When an operating system can not avoid using TSC in the
76	short-term, the operating system will need to either
77	re-synchronize the TSC of the halted core when exiting halt
78	or disable C1-clock ramping. The pseudo-code for disabling
79	C1-clock ramping follows:
80
81	if ( !use_AMD_TSC() &&
82	(CPUID.effective_family == 0x0f) &&
83	C1_ramp_8gen() ){
84	for (i=0; i < number_processors; ++i){
85	// Do for all NorthBridges in platform
86	tmp = read_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87);
87	tmp &= 0xFC; // clears pmm7[1:0]
88	write_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87,tmp)
89	}
90	}
91
92
93	Future TSC Directions and Solutions
94	===================================
95	Future AMD processors will provide a TSC that is P-state and
96	C-State invariant and unaffected by STPCLK-throttling. This
97	will make the TSC immune to drift. Because using the TSC
98	for fast timer APIs is a desirable feature that helps
99	performance, AMD has defined a CPUID feature bit that
100	software can test to determine if the TSC is
101	invariant. Issuing a CPUID instruction with an %eax register
102	value of 0x8000_0007, on a processor whose base family is
103	0xF, returns "Advanced Power Management Information" in the
104	%eax, %ebx, %ecx, and %edx registers. Bit 8 of the return
105	%edx is the "TscInvariant" feature flag which is set when
106	TSC is P-state, C-state, and STPCLK-throttling invariant; it
107	is clear otherwise.
108
109	The rate of the invariant TSC is implementation-dependent
110	and will likely not be the frequency of the processor
111	core; however, its period should be short enough such that
112	it is not possible for two back-to-back rdtsc instructions
113	to return the same value. Software which is trying to
114	measure actual processor frequency or cycle-performance
115	should use Performance Event 76h, CPU Clocks not Halted,
116	rather than the TSC to count CPU cycles.
117
118
119
120	*************************************************************
121	Intel
122
123	Pentium M
124	family [06H], models [09H, 0DH]
125	SOL : disable speedstep
126	Pentium 4 processors, Intel Xeon
127	family [0FH], models [00H, 01H, or 02H]
128	SOL : disable speedstep
129
130	Other : ok
131
132	http://download.intel.com/design/Xeon/specupdt/30675712.pdf
133	http://forum.rightmark.org/post.cgi?id=print:6:269&user=%20Dmitri%20Besedin&color=1
134	http://bochs.sourceforge.net/techspec/24161821.pdf cpuid
135
136	cpuz
137	AFAIK this problem only concerns Prescott CPUs, but I bet future production will
138	also use the same rule.
139
140	Well, from what Intel states in one of their docs (Intel(R) Pentium(R) M
141	Processor on 90 nm Process with 2-MB L2 Cache, Specification Update, Document
142	No. 302209-010 (http://www.intel.com/design/mobile/specupdt/302209.htm) ), your
143	supposition is true:
144
145
146	Article V. For Pentium M processors (family [06H], models [09H, 0DH]); for
147	Pentium 4 processors, Intel Xeon processors (family [0FH], models [00H, 01H, or
148	02H]); and for P6 family processors: the timestamp counter increments with every
149	internal processor clock cycle. The internal processor clock cycle is determined
150	by the current core-clock to bus-clock ratio. Intel(R) SpeedStep(R) technology
151	transitions may also impact the processor clock.
152
153	Article VI. For Pentium 4 processors, Intel Xeon processors (family [0FH],
154	models [03H and higher]): the time-stamp counter increments at a constant rate.
155	That rate may be set by the maximum core-clock to bus-clock ratio of the
156	processor or may be set by the frequency at which the processor is booted. The
157	specific processor configuration determines the behavior. Constant TSC behavior
158	ensures that the duration of each clock tick is uniform and supports the use of
159	the TSC as a wall clock timer even if the processor core changes frequency. This
160	is the architectural behavior moving forward.
161
162
163	It's a pity they call this sucking TSC behavior an "architectural behavior
164	moving forward"
165
166
167
168	*************************************************************
169	HPET
170
171	http://www.intel.com/hardwaredesign/hpetspec_1.pdf
172
173
174
175