1. 21 6月, 2017 1 次提交
    • K
      perf stat: Add support to measure SMI cost · daefd0bc
      Kan Liang 提交于
      Implementing a new --smi-cost mode in perf stat to measure SMI cost.
      
      During the measurement, the /sys/device/cpu/freeze_on_smi will be set.
      
      The measurement can be done with one counter (unhalted core cycles), and
      two free running MSR counters (IA32_APERF and SMI_COUNT).
      
      In practice, the percentages of SMI core cycles should be more useful
      than absolute value. So the output will be the percentage of SMI core
      cycles and SMI#. metric_only will be set by default.
      
      SMI cycles% = (aperf - unhalted core cycles) / aperf
      
      Here is an example output.
      
       Performance counter stats for 'sudo echo ':
      
      SMI cycles%          SMI#
          0.1%              1
      
             0.010858678 seconds time elapsed
      
      Users who wants to get the actual value can apply additional
      --no-metric-only.
      Signed-off-by: NKan Liang <Kan.liang@intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Elliott <elliott@hpe.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1495825538-5230-3-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      daefd0bc
  2. 20 4月, 2017 2 次提交
  3. 20 2月, 2017 1 次提交
  4. 23 6月, 2016 1 次提交
  5. 07 6月, 2016 1 次提交
  6. 10 5月, 2016 1 次提交
  7. 04 2月, 2016 1 次提交
    • J
      perf stat: Fix interval output values · 51fd2df1
      Jiri Olsa 提交于
      We broke interval data displays with commit:
      
        3f416f22 ("perf stat: Do not clean event's private stats")
      
      This commit removed stats cleaning, which is important for '-r' option
      to carry counters data over the whole run. But it's necessary to clean
      it for interval mode, otherwise the displayed value is avg of all
      previous values.
      
      Before:
        $ perf stat -e cycles -a -I 1000 record
        #           time             counts unit events
             1.000240796         75,216,287      cycles
             2.000512791        107,823,524      cycles
      
        $ perf stat report
        #           time             counts unit events
             1.000240796         75,216,287      cycles
             2.000512791         91,519,906      cycles
      
      Now:
        $ perf stat report
        #           time             counts unit events
             1.000240796         75,216,287      cycles
             2.000512791        107,823,524      cycles
      
      Notice the second value being bigger (91,.. < 107,..).
      
      This could be easily verified by using perf script which displays raw
      stat data:
      
        $ perf script
        CPU  THREAD       VAL         ENA         RUN        TIME EVENT
          0      -1  23855779  1000209530  1000209530  1000240796 cycles
          1      -1  33340397  1000224964  1000224964  1000240796 cycles
          2      -1  15835415  1000226695  1000226695  1000240796 cycles
          3      -1   2184696  1000228245  1000228245  1000240796 cycles
          0      -1  97014312  2000514533  2000514533  2000512791 cycles
          1      -1  46121497  2000543795  2000543795  2000512791 cycles
          2      -1  32269530  2000543566  2000543566  2000512791 cycles
          3      -1   7634472  2000544108  2000544108  2000512791 cycles
      
      The sum of the first 4 values is the first interval aggregated value:
      
        23855779 + 33340397 + 15835415 + 2184696 = 75,216,287
      
      The sum of the second 4 values minus first value is the second interval
      aggregated value:
      
        97014312 + 46121497 + 32269530 + 7634472 - 75216287 = 107,823,524
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1454485436-20639-1-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      51fd2df1
  8. 26 1月, 2016 2 次提交
  9. 18 12月, 2015 2 次提交
  10. 20 10月, 2015 3 次提交
  11. 17 9月, 2015 1 次提交
    • S
      perf stat: Fix per-pkg event reporting bug · 02d8dabc
      Stephane Eranian 提交于
      Per-pkg events need to be captured once per processor socket. The code
      in check_per_pkg() ensures only one value per processor package is used.
      However there is a problem with this function in case the first CPU of
      the package does not measure anything for the per-pkg event, but other
      CPUs do.
      
      Consider the following:
      
        $ create cgroup FOO; echo $$ >FOO/tasks; taskset -c 1 noploop &
        $ perf stat -a -I 1000 -e intel_cqm/llc_occupancy/ -G FOO sleep 100
          1.00000 <not counted> Bytes intel_cqm/llc_occupancy/  FOO
      
      The reason for this is that CPU0 in the cgroup has nothing running on it.
      Yet check_per_plg() will mark socket0 as processed and no other event
      value will be considered for the socket.
      
      This patch fixes the problem by having check_per_pkg() only consider
      events which actually ran.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1441286620-10117-1-git-send-email-eranian@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      02d8dabc
  12. 09 8月, 2015 1 次提交
  13. 07 8月, 2015 1 次提交
  14. 26 6月, 2015 7 次提交
  15. 16 6月, 2015 2 次提交
  16. 08 6月, 2015 2 次提交
  17. 08 8月, 2013 1 次提交
  18. 28 5月, 2013 1 次提交
  19. 18 9月, 2012 1 次提交