cpupower-monitor.1 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198
  1. .TH CPUPOWER\-MONITOR "1" "22/02/2011" "" "cpupower Manual"
  2. .SH NAME
  3. cpupower\-monitor \- Report processor frequency and idle statistics
  4. .SH SYNOPSIS
  5. .ft B
  6. .B cpupower monitor
  7. .RB "\-l"
  8. .B cpupower monitor
  9. .RB [ -c ] [ "\-m <mon1>," [ "<mon2>,..." ] ]
  10. .RB [ "\-i seconds" ]
  11. .br
  12. .B cpupower monitor
  13. .RB [ -c ][ "\-m <mon1>," [ "<mon2>,..." ] ]
  14. .RB command
  15. .br
  16. .SH DESCRIPTION
  17. \fBcpupower-monitor \fP reports processor topology, frequency and idle power
  18. state statistics. Either \fBcommand\fP is forked and
  19. statistics are printed upon its completion, or statistics are printed periodically.
  20. \fBcpupower-monitor \fP implements independent processor sleep state and
  21. frequency counters. Some are retrieved from kernel statistics, some are
  22. directly reading out hardware registers. Use \-l to get an overview which are
  23. supported on your system.
  24. .SH Options
  25. .PP
  26. \-l
  27. .RS 4
  28. List available monitors on your system. Additional details about each monitor
  29. are shown:
  30. .RS 2
  31. .IP \(bu
  32. The name in quotation marks which can be passed to the \-m parameter.
  33. .IP \(bu
  34. The number of different counters the monitor supports in brackets.
  35. .IP \(bu
  36. The amount of time in seconds the counters might overflow, due to
  37. implementation constraints.
  38. .IP \(bu
  39. The name and a description of each counter and its processor hierarchy level
  40. coverage in square brackets:
  41. .RS 4
  42. .IP \(bu
  43. [T] \-> Thread
  44. .IP \(bu
  45. [C] \-> Core
  46. .IP \(bu
  47. [P] \-> Processor Package (Socket)
  48. .IP \(bu
  49. [M] \-> Machine/Platform wide counter
  50. .RE
  51. .RE
  52. .RE
  53. .PP
  54. \-m <mon1>,<mon2>,...
  55. .RS 4
  56. Only display specific monitors. Use the monitor string(s) provided by \-l option.
  57. .RE
  58. .PP
  59. \-i seconds
  60. .RS 4
  61. Measure intervall.
  62. .RE
  63. .PP
  64. \-c
  65. .RS 4
  66. Schedule the process on every core before starting and ending measuring.
  67. This could be needed for the Idle_Stats monitor when no other MSR based
  68. monitor (has to be run on the core that is measured) is run in parallel.
  69. This is to wake up the processors from deeper sleep states and let the
  70. kernel re
  71. -account its cpuidle (C-state) information before reading the
  72. cpuidle timings from sysfs.
  73. .RE
  74. .PP
  75. command
  76. .RS 4
  77. Measure idle and frequency characteristics of an arbitrary command/workload.
  78. The executable \fBcommand\fP is forked and upon its exit, statistics gathered since it was
  79. forked are displayed.
  80. .RE
  81. .PP
  82. \-v
  83. .RS 4
  84. Increase verbosity if the binary was compiled with the DEBUG option set.
  85. .RE
  86. .SH MONITOR DESCRIPTIONS
  87. .SS "Idle_Stats"
  88. Shows statistics of the cpuidle kernel subsystem. Values are retrieved from
  89. /sys/devices/system/cpu/cpu*/cpuidle/state*/.
  90. The kernel updates these values every time an idle state is entered or
  91. left. Therefore there can be some inaccuracy when cores are in an idle
  92. state for some time when the measure starts or ends. In worst case it can happen
  93. that one core stayed in an idle state for the whole measure time and the idle
  94. state usage time as exported by the kernel did not get updated. In this case
  95. a state residency of 0 percent is shown while it was 100.
  96. .SS "Mperf"
  97. The name comes from the aperf/mperf (average and maximum) MSR registers used
  98. which are available on recent X86 processors. It shows the average frequency
  99. (including boost frequencies).
  100. The fact that on all recent hardware the mperf timer stops ticking in any idle
  101. state it is also used to show C0 (processor is active) and Cx (processor is in
  102. any sleep state) times. These counters do not have the inaccuracy restrictions
  103. the "Idle_Stats" counters may show.
  104. May work poorly on Linux-2.6.20 through 2.6.29, as the \fBacpi-cpufreq \fP
  105. kernel frequency driver periodically cleared aperf/mperf registers in those
  106. kernels.
  107. .SS "Nehalem" "SandyBridge" "HaswellExtended"
  108. Intel Core and Package sleep state counters.
  109. Threads (hyperthreaded cores) may not be able to enter deeper core states if
  110. its sibling is utilized.
  111. Deepest package sleep states may in reality show up as machine/platform wide
  112. sleep states and can only be entered if all cores are idle. Look up Intel
  113. manuals (some are provided in the References section) for further details.
  114. The monitors are named after the CPU family where the sleep state capabilities
  115. got introduced and may not match exactly the CPU name of the platform.
  116. For example an IvyBridge processor has sleep state capabilities which got
  117. introduced in Nehalem and SandyBridge processor families.
  118. Thus on an IvyBridge processor one will get Nehalem and SandyBridge sleep
  119. state monitors.
  120. HaswellExtended extra package sleep state capabilities are available only in a
  121. specific Haswell (family 0x45) and probably also other future processors.
  122. .SS "Fam_12h" "Fam_14h"
  123. AMD laptop and desktop processor (family 12h and 14h) sleep state counters.
  124. The registers are accessed via PCI and therefore can still be read out while
  125. cores have been offlined.
  126. There is one special counter: NBP1 (North Bridge P1).
  127. This one always returns 0 or 1, depending on whether the North Bridge P1
  128. power state got entered at least once during measure time.
  129. Being able to enter NBP1 state also depends on graphics power management.
  130. Therefore this counter can be used to verify whether the graphics' driver
  131. power management is working as expected.
  132. .SH EXAMPLES
  133. cpupower monitor -l" may show:
  134. .RS 4
  135. Monitor "Mperf" (3 states) \- Might overflow after 922000000 s
  136. ...
  137. Monitor "Idle_Stats" (3 states) \- Might overflow after 4294967295 s
  138. ...
  139. .RE
  140. cpupower monitor \-m "Idle_Stats,Mperf" scp /tmp/test /nfs/tmp
  141. Monitor the scp command, show both Mperf and Idle_Stats states counter
  142. statistics, but in exchanged order.
  143. .RE
  144. Be careful that the typical command to fully utilize one CPU by doing:
  145. cpupower monitor cat /dev/zero >/dev/null
  146. Does not work as expected, because the measured output is redirected to
  147. /dev/null. This could get workarounded by putting the line into an own, tiny
  148. shell script. Hit CTRL\-c to terminate the command and get the measure output
  149. displayed.
  150. .SH REFERENCES
  151. "BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 14h Processors"
  152. http://support.amd.com/us/Processor_TechDocs/43170.pdf
  153. "Intel® Turbo Boost Technology
  154. in Intel® Core™ Microarchitecture (Nehalem) Based Processors"
  155. http://download.intel.com/design/processor/applnots/320354.pdf
  156. "Intel® 64 and IA-32 Architectures Software Developer's Manual
  157. Volume 3B: System Programming Guide"
  158. http://www.intel.com/products/processor/manuals
  159. .SH FILES
  160. .ta
  161. .nf
  162. /dev/cpu/*/msr
  163. /sys/devices/system/cpu/cpu*/cpuidle/state*/.
  164. .fi
  165. .SH "SEE ALSO"
  166. powertop(8), msr(4), vmstat(8)
  167. .PP
  168. .SH AUTHORS
  169. .nf
  170. Written by Thomas Renninger <trenn@suse.de>
  171. Nehalem, SandyBridge monitors and command passing
  172. based on turbostat.8 from Len Brown <len.brown@intel.com>