1. 09 2月, 2013 1 次提交
  2. 30 11月, 2012 5 次提交
    • J
      tools: Allow tools to be installed in a user specified location · 55f1f545
      Josh Boyer 提交于
      When building x86_energy_perf_policy or turbostat within the confines of
      a packaging system such as RPM, we need to be able to have it install to
      the buildroot and not the root filesystem of the build machine.  This
      adds a DESTDIR variable that when set will act as a prefix for the
      install location of these tools.
      Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      55f1f545
    • M
      tools/power: turbostat: make Makefile a bit more capable · ee0778a3
      Mark Asselstine 提交于
      The turbostat Makefile is pretty simple, its output is placed in the
      same directory as the source, the install rule has no concept of a
      prefix or sysroot, and you can set CC to use a specific compiler but
      not use the more familiar CROSS_COMPILE. By making a few minor changes
      these limitations are removed while leaving the default behavior
      matching what it used to be.
      
      Example build with these changes:
      make CROSS_COMPILE=i686-wrs-linux-gnu- DESTDIR=/tmp install
      
      or from the tools directory
      make CROSS_COMPILE=i686-wrs-linux-gnu- DESTDIR=/tmp turbostat_install
      Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ee0778a3
    • C
      tools/power x86_energy_perf_policy: close /proc/stat in for_every_cpu() · 84764a41
      Colin Ian King 提交于
      Instead of returning out of for_every_cpu() we should break out of the loop=
       which will then tidy up correctly by closing the file /proc/stat.
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      84764a41
    • L
      tools/power turbostat: v3.0: monitor Watts and Temperature · 889facbe
      Len Brown 提交于
      Show power in Watts and temperature in Celsius
      when hardware support is present.
      
      Intel's Sandy Bridge and Ivy Bridge processor generations support RAPL
      (Run-Time-Average-Power-Limiting).  Per the Intel SDM
      (Intel® 64 and IA-32 Architectures Software Developer Manual)
      RAPL provides hardware energy counters and power control MSRs
      (Model Specific Registers).  RAPL MSRs are designed primarily
      as a method to implement power capping.  However, they are useful
      for monitoring system power whether or not power capping is used.
      
      In addition, Turbostat now shows temperature from DTS
      (Digital Thermal Sensor) and PTM (Package Thermal Monitor) hardware,
      if present.
      
      As before, turbostat reads MSRs, and never writes MSRs.
      
      New columns are present in turbostat output:
      
      The Pkg_W column shows Watts for each package (socket) in the system.
      On multi-socket systems, the system summary on the 1st row shows the sum
      for all sockets together.
      
      The Cor_W column shows Watts due to processors cores.
      Note that Core_W is included in Pkg_W.
      
      The optional GFX_W column shows Watts due to the graphics "un-core".
      Note that GFX_W is included in Pkg_W.
      
      The optional RAM_W column on server processors shows Watts due to DRAM DIMMS.
      As DRAM DIMMs are outside the processor package, RAM_W is not included in Pkg_W.
      
      The optional PKG_% and RAM_% columns on server processors shows the % of time
      in the measurement interval that RAPL power limiting is in effect on the
      package and on DRAM.
      
      Note that the RAPL energy counters have some limitations.
      
      First, hardware updates the counters about once every milli-second.
      This is fine for typical turbostat measurement intervals > 1 sec.
      However, when turbostat is used to measure events that approach
      1ms, the counters are less useful.
      
      Second, the 32-bit energy counters are subject to wrapping.
      For example, a counter incrementing 15 micro-Joule units
      on a 130 Watt TDP server processor could (in theory)
      roll over in about 9 minutes.  Turbostat detects and handles
      up to 1 counter overflow per measurement interval.
      But when the measurement interval exceeds the guaranteed
      counter range, we can't detect if more than 1 overflow occured.
      So in this case turbostat indicates that the results are
      in question by replacing the fractional part of the Watts
      in the output with "**":
      
      Pkg_W  Cor_W GFX_W
        3**    0**   0**
      
      Third, the RAPL counters are energy (Joule) counters -- they sum up
      weighted events in the package to estimate energy consumed.  They are
      not analong power (Watt) meters.  In practice, they tend to under-count
      because they don't cover every possible use of energy in the package.
      The accuracy of the RAPL counters will vary between product generations,
      and between SKU's in the same product generation, and with temperature.
      
      turbostat's -v (verbose) option now displays more power and thermal configuration
      information -- as shown on the turbostat.8 manual page.
      For example, it now displays the Package and DRAM Thermal Design Power (TDP):
      
      cpu0: MSR_PKG_POWER_INFO: 0x2f064001980410 (130 W TDP, RAPL 51 - 200 W, 0.045898 sec.)
      cpu0: MSR_DRAM_POWER_INFO,: 0x28025800780118 (35 W TDP, RAPL 15 - 75 W, 0.039062 sec.)
      cpu8: MSR_PKG_POWER_INFO: 0x2f064001980410 (130 W TDP, RAPL 51 - 200 W, 0.045898 sec.)
      cpu8: MSR_DRAM_POWER_INFO,: 0x28025800780118 (35 W TDP, RAPL 15 - 75 W, 0.039062 sec.)
      Signed-off-by: NLen Brown <len.brown@intel.com>
      889facbe
    • L
      tools/power turbostat: fix output buffering issue · ddac0d68
      Len Brown 提交于
      In periodic mode, turbostat writes to stdout,
      but users were un-able to re-direct stdout, eg.
      
      turbostat > outputfile
      
      would result in an empty outputfile.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ddac0d68
  3. 28 11月, 2012 8 次提交
  4. 27 11月, 2012 1 次提交
    • L
      tools/power turbostat: prevent infinite loop on migration error path · e52966c0
      Len Brown 提交于
      Turbostat assumed if it can't migrate to a CPU, then the CPU
      must have gone off-line and turbostat should re-initialize
      with the new topology.
      
      But if turbostat can not migrate because it is restricted by
      a cpuset, then it will fail to migrate even after re-initialization,
      resulting in an infinite loop.
      
      Spit out a warning when we can't migrate
      and endure only 2 re-initialize cycles in a row
      before giving up and exiting.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e52966c0
  5. 24 11月, 2012 1 次提交
  6. 01 11月, 2012 2 次提交
  7. 09 10月, 2012 1 次提交
  8. 07 10月, 2012 1 次提交
  9. 03 10月, 2012 1 次提交
    • J
      kbuild: Fix gcc -x syntax · b1e0d8b7
      Jean Delvare 提交于
      The correct syntax for gcc -x is "gcc -x assembler", not
      "gcc -xassembler". Even though the latter happens to work, the former
      is what is documented in the manual page and thus what gcc wrappers
      such as icecream do expect.
      
      This isn't a cosmetic change. The missing space prevents icecream from
      recognizing compilation tasks it can't handle, leading to silent kernel
      miscompilations.
      
      Besides me, credits go to Michael Matz and Dirk Mueller for
      investigating the miscompilation issue and tracking it down to this
      incorrect -x parameter syntax.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Bernhard Walle <bernhard@bwalle.de>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      b1e0d8b7
  10. 28 9月, 2012 1 次提交
  11. 27 9月, 2012 5 次提交
  12. 25 9月, 2012 2 次提交
  13. 23 9月, 2012 6 次提交
  14. 20 7月, 2012 2 次提交
    • L
      tools/power: turbostat: fix large c1% issue · c3ae331d
      Len Brown 提交于
      Under some conditions, c1% was displayed as very large number,
      much higher than 100%.
      
      c1% is not measured, it is derived as "that, which is left over"
      from other counters.  However, the other counters are not collected
      atomically, and so it is possible for c1% to be calaculagted as
      a small negative number -- displayed as very large positive.
      
      There was a check for mperf vs tsc for this already,
      but it needed to also include the other counters
      that are used to calculate c1.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c3ae331d
    • L
      tools/power: turbostat v2 - re-write for efficiency · c98d5d94
      Len Brown 提交于
      Measuring large profoundly-idle configurations
      requires turbostat to be more lightweight.
      Otherwise, the operation of turbostat itself
      can interfere with the measurements.
      
      This re-write makes turbostat topology aware.
      Hardware is accessed in "topology order".
      Redundant hardware accesses are deleted.
      Redundant output is deleted.
      Also, output is buffered and
      local RDTSC use replaces remote MSR access for TSC.
      
      From a feature point of view, the output
      looks different since redundant figures are absent.
      Also, there are now -c and -p options -- to restrict
      output to the 1st thread in each core, and the 1st
      thread in each package, respectively.  This is helpful
      to reduce output on big systems, where more detail
      than the "-s" system summary is desired.
      Finally, periodic mode output is now on stdout, not stderr.
      
      Turbostat v2 is also slightly more robust in
      handling run-time CPU online/offline events,
      as it now checks the actual map of on-line cpus rather
      than just the total number of on-line cpus.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c98d5d94
  15. 04 6月, 2012 2 次提交
    • L
      tools/power turbostat: fix IVB support · 650a37f3
      Len Brown 提交于
      Initial IVB support went into turbostat in Linux-3.1:
      553575f1
      (tools turbostat: recognize and run properly on IVB)
      
      However, when running on IVB, turbostat would fail
      to report the new couters added with SNB, c7, pc2 and pc7.
      So in scenarios where these counters are non-zero on IVB,
      turbostat would report erroneous residencey results.
      
      In particular c7 time would be added to c1 time,
      since c1 time is calculated as "that which is left over".
      
      Also, turbostat reports MHz capabilities when passed
      the "-v" option, and it would incorrectly report 133MHz
      bclk instead of 100MHz bclk for IVB, which would inflate
      GHz reported with that option.
      
      This patch is a backport of a fix already included in turbostat v2.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      650a37f3
    • L
      tools/power turbostat: fix un-intended affinity of forked program · d15cf7c1
      Len Brown 提交于
      Linux 3.4 included a modification to turbostat to
      lower cross-call overhead by using scheduler affinity:
      
      15aaa346
      (tools turbostat: reduce measurement overhead due to IPIs)
      
      In the use-case where turbostat forks a child program,
      that change had the un-intended side-effect of binding
      the child to the last cpu in the system.
      
      This change removed the binding before forking the child.
      
      This is a back-port of a fix already included in turbostat v2.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d15cf7c1
  16. 17 5月, 2012 1 次提交
    • P
      sched: Remove stale power aware scheduling remnants and dysfunctional knobs · 8e7fbcbc
      Peter Zijlstra 提交于
      It's been broken forever (i.e. it's not scheduling in a power
      aware fashion), as reported by Suresh and others sending
      patches, and nobody cares enough to fix it properly ...
      so remove it to make space free for something better.
      
      There's various problems with the code as it stands today, first
      and foremost the user interface which is bound to topology
      levels and has multiple values per level. This results in a
      state explosion which the administrator or distro needs to
      master and almost nobody does.
      
      Furthermore large configuration state spaces aren't good, it
      means the thing doesn't just work right because it's either
      under so many impossibe to meet constraints, or even if
      there's an achievable state workloads have to be aware of
      it precisely and can never meet it for dynamic workloads.
      
      So pushing this kind of decision to user-space was a bad idea
      even with a single knob - it's exponentially worse with knobs
      on every node of the topology.
      
      There is a proposal to replace the user interface with a single
      3 state knob:
      
       sched_balance_policy := { performance, power, auto }
      
      where 'auto' would be the preferred default which looks at things
      like Battery/AC mode and possible cpufreq state or whatever the hw
      exposes to show us power use expectations - but there's been no
      progress on it in the past many months.
      
      Aside from that, the actual implementation of the various knobs
      is known to be broken. There have been sporadic attempts at
      fixing things but these always stop short of reaching a mergable
      state.
      
      Therefore this wholesale removal with the hopes of spurring
      people who care to come forward once again and work on a
      coherent replacement.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1326104915.2442.53.camel@twinsSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8e7fbcbc