1. 12 1月, 2013 1 次提交
  2. 18 12月, 2012 9 次提交
  3. 12 12月, 2012 5 次提交
  4. 06 12月, 2012 1 次提交
  5. 03 12月, 2012 2 次提交
  6. 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
  7. 28 11月, 2012 8 次提交
  8. 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
  9. 24 11月, 2012 3 次提交
  10. 20 11月, 2012 5 次提交
    • D
      perf: Make perf build for x86 with UAPI disintegration applied · d2709c7c
      David Howells 提交于
      Make perf build for x86 once the UAPI disintegration patches for that arch
      have been applied by adding the appropriate -I flags - in the right order -
      and then converting some #includes that use ../.. notation to find main kernel
      headerfiles to use <asm/foo.h> and <linux/foo.h> instead.
      
      Note that -Iarch/foo/include/uapi is present _before_ -Iarch/foo/include.
      This makes sure we get the userspace version of the pt_regs struct.  Ideally,
      we wouldn't have the latter -I flag at all, but unfortunately we want
      asm/svm.h and asm/vmx.h in builtin-kvm.c and these aren't part of the UAPI -
      at least not for x86.  I wonder if the bits outside of the __KERNEL__ guards
      *should* be transferred there.
      
      I note also that perf seems to do its dependency handling manually by listing
      all the header files it might want to use in LIB_H in the Makefile.  Can this
      be changed to use -MD?
      
      Note that to do make this work, we need to export and UAPI disintegrate
      linux/hw_breakpoint.h, which I think should've been exported previously so that
      perf can access the bits.  We have to do this in the same patch to maintain
      bisectability.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d2709c7c
    • S
      perf powerpc: Use uapi/unistd.h to fix build error · f2d9cae9
      Sukadev Bhattiprolu 提交于
      Use the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool.
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Cc: Anton Blanchard <anton@au1.ibm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: linuxppc-dev@ozlabs.org
      Link: http://lkml.kernel.org/r/20121107191818.GA16211@us.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f2d9cae9
    • D
      tools: Pass the target in descend · 2b73f65d
      David Howells 提交于
       Fixing:
      
        [acme@sandy linux]$ cd tools
        [acme@sandy tools]$ make clean
            DESCEND power/cpupower
          CC       lib/cpufreq.o
          CC       lib/sysfs.o
          LD       libcpupower.so.0.0.0
          CC       utils/helpers/amd.o
        utils/helpers/amd.c:7:21: error: pci/pci.h: No such file or directory
        In file included from utils/helpers/amd.c:9:
        ./utils/helpers/helpers.h:137: warning: ‘struct pci_access’ declared inside parameter list
        ./utils/helpers/helpers.h:137: warning: its scope is only this definition or declaration, which is probably not what you want
        ./utils/helpers/helpers.h:139: warning: ‘struct pci_access’ declared inside parameter list
        utils/helpers/amd.c: In function ‘amd_pci_get_num_boost_states’:
        utils/helpers/amd.c:120: warning: passing argument 1 of ‘pci_slot_func_init’ from incompatible pointer type
        ./utils/helpers/helpers.h:138: note: expected ‘struct pci_access **’ but argument is of type ‘struct pci_access **’
        utils/helpers/amd.c:125: warning: implicit declaration of function ‘pci_read_byte’
        utils/helpers/amd.c:132: warning: implicit declaration of function ‘pci_cleanup’
        make[1]: *** [utils/helpers/amd.o] Error 1
        make: *** [cpupower_clean] Error 2
        [acme@sandy tools]$
      Reported-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/n/tip-tviyimq6x6nm77sj5lt4t19f@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2b73f65d
    • D
      tools: Honour the O= flag when tool build called from a higher Makefile · bf35182f
      David Howells 提交于
      Honour the O= flag that was passed to a higher level Makefile and then passed
      down as part of a tool build.
      
      To make this work, the top-level Makefile passes the original O= flag and
      subdir=tools to the tools/Makefile, and that in turn passes
      subdir=$(O)/$(subdir)/foodir when building tool foo in directory
      $(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
      element is missing).
      
      For example, take perf.  This is found in tools/perf/.  Assume we're building
      into directory ~/zebra/, so we pass O=~/zebra to make.  Dependening on where
      we run the build from, we see:
      
      	make run in dir		$(OUTPUT) dir
      	=======================	==================
      	linux			~/zebra/tools/perf/
      	linux/tools		~/zebra/perf/
      	linux/tools/perf	~/zebra/
      
      and if O= is not set, we get:
      
      	make run in dir		$(OUTPUT) dir
      	=======================	==================
      	linux			linux/tools/perf/
      	linux/tools		linux/tools/perf/
      	linux/tools/perf	linux/tools/perf/
      
      The output directories are created by the descend function if they don't
      already exist.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.ukSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bf35182f
    • D
      tools: Define a Makefile function to do subdir processing · ca9dfc6c
      David Howells 提交于
      Define a Makefile function that can be called with $(call ...) to wrap
      the subdir make invocations in tools/Makefile.
      
      This will allow us in the next patch to insert bits in there to honour
      O= flags when called from the top-level Makefile.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.ukSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ca9dfc6c