One - The Linux Kernel Archives

More documents

Recommendations

Info

174 • Linux Symposium 2004 • Volume One DDR AMD Opteron TM Processor cHT AMD Opteron TM Processor DDR ncHT ncHT 8X AGP AMD 8151 TM Graphics Tunnel AMD 8131 TM PCI-X Tunnel PCI-X ncHT Legacy PCI USB LPC AMD 8111 TM I/O Hub AC ‘97 EIDE Figure 1: Two Processor System Processor 100MHz 133MHz 166MHz 200MHz Core DRAM DRAM DRAM DRAM Frequency spec spec spec spec 800MHz 100.00 133.33 160.00 160.00 1000MHz 100.00 125.00 166.66 200.00 2000MHz 100.00 133.33 166.66 200.00 2200MHz 100.00 129.41 157.14 200.00 Table 2: DRAM Frequencies For A Range Of Processor Core Frequencies
Linux Symposium 2004 • Volume One • 175 7.5 TSC Varying The Time Stamp Counter (TSC) register is a register that increments with the processor clock. Multiple reads of the register will see increasing values. This register increments on each core clock cycle in the current generation of processors. Thus, the rate of increase of the TSC when compared with “wall clock time” varies as the frequency varies. This causes problems in code that calibrates the TSC increments against an external time source, and then attempts to use the TSC to measure time. The Linux kernel uses the TSC for such timings, for example when a driver calls udelay(). In this case it is not a disaster if the udelay() call waits for too long as the call is defined to allow this behavior. The case of the udelay() call returning too quickly can be fatal, and this has been demonstrated during experimentation with this code. This particular problem is resolved by the cpufreq driver correcting the kernel TSC calibration whenever the frequency changes. This issue may impact other code that uses the TSC register directly. It is interesting to note that it is hard to define a correct behavior. Code that calibrates the TSC against an external clock will be thrown off if the rate of increment of the TSC should change. However, other code may expect a certain code sequence to consistently execute in approximately the same number of cycles, as measured by the TSC, and this code will be thrown off if the behavior of the TSC changes relative to the processor speed. 7.6 Measurement Of Frequency Transition Times The time required to perform a transition is a combination of the software time to execute the required code, and the hardware time to perform the transition. Examples of hardware wait time are: • waiting for the VRM to be stable at a newer voltage, • waiting for the PLL to lock at the new frequency, • waiting for DRAM to be placed into and then taken out of self refresh mode around a frequency transition. The time taken to transition between two states is dependent on both the initial state and the target state. This is due to : • multiple steps being required in some cases, • certain operations are lengthier (for example, voltage is stepped up in multiple stages, but stepped down in a single step), • difference in code execution time dependent on processor speed (although this is minor). Measurements, taken by calibrating the frequency driver, show that frequency transitions for a processor are taking less than 0.015 seconds. Further experimentation with multiple processors showed a worst case transition time of less than 0.08 seconds to transition all 4 processors from minimum to maximum frequency, and slightly faster to transition from maximum to minimum frequency. Note, there is a driver optimization under consideration that would approximately halve these transition times.
Page 1:
Proceedings of the Linux Symposium
Page 4 and 5:
The State of ACPI in the Linux Kern
Page 7 and 8:
Conference Organizers Andrew J. Hut
Page 9 and 10:
TCP Connection Passing Werner Almes
Page 11 and 12:
Linux Symposium 2004 • Volume One
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Cooperative Linux Dan Aloni da-x@co
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Build your own Wireless Access Poin
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Run-time testing of LSB Application
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Linux Block IO—present and future
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Linux AIO Performance and Robustnes
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Methods to Improve Bootup Time in L
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Linux on NUMA Systems Martin J. Bli
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Improving Kernel Performance by Unm
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Linux Virtualization on IBM POWER5
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
The State of ACPI in the Linux Kern
Page 123 and 124: Linux Symposium 2004 • Volume One
Page 133 and 134: Scaling Linux® to the Extreme From
Page 149 and 150: Get More Device Drivers out of the
Page 163 and 164: Big Servers—2.6 compared to 2.4 W
Page 167 and 168: Multi-processor and Frequency Scali
Page 173: Linux Symposium 2004 • Volume One
Page 187 and 188: Dynamic Kernel Module Support: From
Page 203 and 204: e100 Weight Reduction Program Writi
Page 207 and 208: NFSv4 and rpcsec_gss for linux J. B
Page 215 and 216: Comparing and Evaluating epoll, sel
Page 225 and 226:
Page 227 and 228:
The (Re)Architecture of the X Windo
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
IA64-Linux perf tools for IO dorks
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
Page 247 and 248:
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256:
Carrier Grade Server Features in th
Page 257 and 258:
Page 259 and 260:
Page 261 and 262:
Page 263 and 264:
Page 265 and 266:
Page 267 and 268:
Page 269 and 270:
Demands, Solutions, and Improvement
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Hotplug Memory and the Linux VM Dav
Page 289 and 290:
Page 291 and 292:
Page 293 and 294:
show all

One - The Linux Kernel Archives

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?