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 | |