1. 06 5月, 2020 14 次提交
  2. 30 4月, 2020 4 次提交
    • K
      perf tools: Enable Hz/hz prinitg for --metric-only option · 3351c6da
      Kajol Jain 提交于
      Commit 54b50916 ("perf stat: Implement --metric-only mode") added
      function 'valid_only_metric()' which drops "Hz" or "hz", if it is part
      of "ScaleUnit". This patch enable it since hv_24x7 supports couple of
      frequency events.
      Signed-off-by: NKajol Jain <kjain@linux.ibm.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Joe Mario <jmario@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@ozlabs.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lore.kernel.org/lkml/20200401203340.31402-7-kjain@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3351c6da
    • K
      perf metricgroups: Enhance JSON/metric infrastructure to handle "?" · 1e1a873d
      Kajol Jain 提交于
      Patch enhances current metric infrastructure to handle "?" in the metric
      expression. The "?" can be use for parameters whose value not known
      while creating metric events and which can be replace later at runtime
      to the proper value. It also add flexibility to create multiple events
      out of single metric event added in JSON file.
      
      Patch adds function 'arch_get_runtimeparam' which is a arch specific
      function, returns the count of metric events need to be created.  By
      default it return 1.
      
      This infrastructure needed for hv_24x7 socket/chip level events.
      "hv_24x7" chip level events needs specific chip-id to which the data is
      requested. Function 'arch_get_runtimeparam' implemented in header.c
      which extract number of sockets from sysfs file "sockets" under
      "/sys/devices/hv_24x7/interface/".
      
      With this patch basically we are trying to create as many metric events
      as define by runtime_param.
      
      For that one loop is added in function 'metricgroup__add_metric', which
      create multiple events at run time depend on return value of
      'arch_get_runtimeparam' and merge that event in 'group_list'.
      
      To achieve that we are actually passing this parameter value as part of
      `expr__find_other` function and changing "?" present in metric
      expression with this value.
      
      As in our JSON file, there gonna be single metric event, and out of
      which we are creating multiple events.
      
      To understand which data count belongs to which parameter value,
      we also printing param value in generic_metric function.
      
      For example,
      
        command:# ./perf stat  -M PowerBUS_Frequency -C 0 -I 1000
          1.000101867  9,356,933  hv_24x7/pm_pb_cyc,chip=0/ #  2.3 GHz  PowerBUS_Frequency_0
          1.000101867  9,366,134  hv_24x7/pm_pb_cyc,chip=1/ #  2.3 GHz  PowerBUS_Frequency_1
          2.000314878  9,365,868  hv_24x7/pm_pb_cyc,chip=0/ #  2.3 GHz  PowerBUS_Frequency_0
          2.000314878  9,366,092  hv_24x7/pm_pb_cyc,chip=1/ #  2.3 GHz  PowerBUS_Frequency_1
      
      So, here _0 and _1 after PowerBUS_Frequency specify parameter value.
      Signed-off-by: NKajol Jain <kjain@linux.ibm.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Joe Mario <jmario@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@ozlabs.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lore.kernel.org/lkml/20200401203340.31402-5-kjain@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1e1a873d
    • Z
      perf tools: Remove unneeded semicolons · 8284bbea
      Zou Wei 提交于
      Fixes coccicheck warnings:
      
        tools/perf/builtin-diff.c:1565:2-3: Unneeded semicolon
        tools/perf/builtin-lock.c:778:2-3: Unneeded semicolon
        tools/perf/builtin-mem.c:126:2-3: Unneeded semicolon
        tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c:555:2-3: Unneeded semicolon
        tools/perf/util/ordered-events.c:317:2-3: Unneeded semicolon
        tools/perf/util/synthetic-events.c:1131:2-3: Unneeded semicolon
        tools/perf/util/trace-event-read.c:78:2-3: Unneeded semicolon
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NZou Wei <zou_wei@huawei.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/1588065523-71423-1-git-send-email-zou_wei@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8284bbea
    • I
      perf synthetic events: Remove use of sscanf from /proc reading · 2069425e
      Ian Rogers 提交于
      The synthesize benchmark, run on a single process and thread, shows
      perf_event__synthesize_mmap_events as the hottest function with fgets
      and sscanf taking the majority of execution time.
      
      fscanf performs similarly well. Replace the scanf call with manual
      reading of each field of the /proc/pid/maps line, and remove some
      unnecessary buffering.
      
      This change also addresses potential, but unlikely, buffer overruns for
      the string values read by scanf.
      
      Performance before is:
      
        $ sudo perf bench internals synthesize -m 16 -M 16 -s -t
        \# Running 'internals/synthesize' benchmark:
        Computing performance of single threaded perf event synthesis by
        synthesizing events on the perf process itself:
          Average synthesis took: 102.810 usec (+- 0.027 usec)
          Average num. events: 17.000 (+- 0.000)
          Average time per event 6.048 usec
          Average data synthesis took: 106.325 usec (+- 0.018 usec)
          Average num. events: 89.000 (+- 0.000)
          Average time per event 1.195 usec
        Computing performance of multi threaded perf event synthesis by
        synthesizing events on CPU 0:
          Number of synthesis threads: 16
            Average synthesis took: 68103.100 usec (+- 441.234 usec)
            Average num. events: 30703.000 (+- 0.730)
            Average time per event 2.218 usec
      
      And after is:
      
        $ sudo perf bench internals synthesize -m 16 -M 16 -s -t
        \# Running 'internals/synthesize' benchmark:
        Computing performance of single threaded perf event synthesis by
        synthesizing events on the perf process itself:
          Average synthesis took: 50.388 usec (+- 0.031 usec)
          Average num. events: 17.000 (+- 0.000)
          Average time per event 2.964 usec
          Average data synthesis took: 52.693 usec (+- 0.020 usec)
          Average num. events: 89.000 (+- 0.000)
          Average time per event 0.592 usec
        Computing performance of multi threaded perf event synthesis by
        synthesizing events on CPU 0:
          Number of synthesis threads: 16
            Average synthesis took: 45022.400 usec (+- 552.740 usec)
            Average num. events: 30624.200 (+- 10.037)
            Average time per event 1.470 usec
      
      On a Intel Xeon 6154 compiling with Debian gcc 9.2.1.
      
      Committer testing:
      
      On a AMD Ryzen 5 3600X 6-Core Processor:
      
      Before:
      
        # perf bench internals synthesize --min-threads 12 --max-threads 12 --st --mt
        # Running 'internals/synthesize' benchmark:
        Computing performance of single threaded perf event synthesis by
        synthesizing events on the perf process itself:
          Average synthesis took: 267.491 usec (+- 0.176 usec)
          Average num. events: 56.000 (+- 0.000)
          Average time per event 4.777 usec
          Average data synthesis took: 277.257 usec (+- 0.169 usec)
          Average num. events: 287.000 (+- 0.000)
          Average time per event 0.966 usec
        Computing performance of multi threaded perf event synthesis by
        synthesizing events on CPU 0:
          Number of synthesis threads: 12
            Average synthesis took: 81599.500 usec (+- 346.315 usec)
            Average num. events: 36096.100 (+- 2.523)
            Average time per event 2.261 usec
        #
      
      After:
      
        # perf bench internals synthesize --min-threads 12 --max-threads 12 --st --mt
        # Running 'internals/synthesize' benchmark:
        Computing performance of single threaded perf event synthesis by
        synthesizing events on the perf process itself:
          Average synthesis took: 110.125 usec (+- 0.080 usec)
          Average num. events: 56.000 (+- 0.000)
          Average time per event 1.967 usec
          Average data synthesis took: 118.518 usec (+- 0.057 usec)
          Average num. events: 287.000 (+- 0.000)
          Average time per event 0.413 usec
        Computing performance of multi threaded perf event synthesis by
        synthesizing events on CPU 0:
          Number of synthesis threads: 12
            Average synthesis took: 43490.700 usec (+- 284.527 usec)
            Average num. events: 37028.500 (+- 0.563)
            Average time per event 1.175 usec
        #
      Signed-off-by: NIan Rogers <irogers@google.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrey Zhizhikin <andrey.z@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lore.kernel.org/lkml/20200415054050.31645-4-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2069425e
  3. 23 4月, 2020 2 次提交
    • S
      perf record: Add num-synthesize-threads option · d99c22ea
      Stephane Eranian 提交于
      To control degree of parallelism of the synthesize_mmap() code which
      is scanning /proc/PID/task/PID/maps and can be time consuming.
      Mimic perf top way of handling the option.
      If not specified will default to 1 thread, i.e. default behavior before
      this option.
      
      On a desktop computer the processing of /proc/PID/task/PID/maps isn't
      slow enough to warrant parallel processing and the thread creation has
      some cost - hence the default of 1. On a loaded server with
      >100 cores it is possible to see synthesis times in the order of
      seconds and in this case having the option is desirable.
      
      As the processing is a synchronization point, it is legitimate to worry if
      Amdahl's law will apply to this patch. Profiling with this patch in
      place:
      https://lore.kernel.org/lkml/20200415054050.31645-4-irogers@google.com/
      shows:
      ...
            - 32.59% __perf_event__synthesize_threads
               - 32.54% __event__synthesize_thread
                  + 22.13% perf_event__synthesize_mmap_events
                  + 6.68% perf_event__get_comm_ids.constprop.0
                  + 1.49% process_synthesized_event
                  + 1.29% __GI___readdir64
                  + 0.60% __opendir
      ...
      That is the processing is 1.49% of execution time and there is plenty to
      make parallel. This is shown in the benchmark in this patch:
      
      https://lore.kernel.org/lkml/20200415054050.31645-2-irogers@google.com/
      
        Computing performance of multi threaded perf event synthesis by
        synthesizing events on CPU 0:
         Number of synthesis threads: 1
           Average synthesis took: 127729.000 usec (+- 3372.880 usec)
           Average num. events: 21548.600 (+- 0.306)
           Average time per event 5.927 usec
         Number of synthesis threads: 2
           Average synthesis took: 88863.500 usec (+- 385.168 usec)
           Average num. events: 21552.800 (+- 0.327)
           Average time per event 4.123 usec
         Number of synthesis threads: 3
           Average synthesis took: 83257.400 usec (+- 348.617 usec)
           Average num. events: 21553.200 (+- 0.327)
           Average time per event 3.863 usec
         Number of synthesis threads: 4
           Average synthesis took: 75093.000 usec (+- 422.978 usec)
           Average num. events: 21554.200 (+- 0.200)
           Average time per event 3.484 usec
         Number of synthesis threads: 5
           Average synthesis took: 64896.600 usec (+- 353.348 usec)
           Average num. events: 21558.000 (+- 0.000)
           Average time per event 3.010 usec
         Number of synthesis threads: 6
           Average synthesis took: 59210.200 usec (+- 342.890 usec)
           Average num. events: 21560.000 (+- 0.000)
           Average time per event 2.746 usec
         Number of synthesis threads: 7
           Average synthesis took: 54093.900 usec (+- 306.247 usec)
           Average num. events: 21562.000 (+- 0.000)
           Average time per event 2.509 usec
         Number of synthesis threads: 8
           Average synthesis took: 48938.700 usec (+- 341.732 usec)
           Average num. events: 21564.000 (+- 0.000)
           Average time per event 2.269 usec
      
      Where average time per synthesized event goes from 5.927 usec with 1
      thread to 2.269 usec with 8. This isn't a linear speed up as not all of
      synthesize code has been made parallel. If the synthesis time was about
      10 seconds then using 8 threads may bring this down to less than 4.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Reviewed-by: NIan Rogers <irogers@google.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tony Jones <tonyj@suse.de>
      Cc: yuzhoujian <yuzhoujian@didichuxing.com>
      Link: http://lore.kernel.org/lkml/20200422155038.9380-1-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d99c22ea
    • J
      perf stat: Zero all the 'ena' and 'run' array slot stats for interval mode · 0e0bf1ea
      Jin Yao 提交于
      As the code comments in perf_stat_process_counter() say, we calculate
      counter's data every interval, and the display code shows ps->res_stats
      avg value. We need to zero the stats for interval mode.
      
      But the current code only zeros the res_stats[0], it doesn't zero the
      res_stats[1] and res_stats[2], which are for ena and run of counter.
      
      This patch zeros the whole res_stats[] for interval mode.
      
      Fixes: 51fd2df1 ("perf stat: Fix interval output values")
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20200409070755.17261-1-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0e0bf1ea
  4. 22 4月, 2020 2 次提交
  5. 18 4月, 2020 18 次提交
    • K
      perf hist: Add fast path for duplicate entries check · 12e89e65
      Kan Liang 提交于
      Perf checks the duplicate entries in a callchain before adding an entry.
      However the check is very slow especially with deeper call stack.
      Almost ~50% elapsed time of perf report is spent on the check when the
      call stack is always depth of 32.
      
      The hist_entry__cmp() is used to compare the new entry with the old
      entries. It will go through all the available sorts in the sort_list,
      and call the specific cmp of each sort, which is very slow.
      
      Actually, for most cases, there are no duplicate entries in callchain.
      The symbols are usually different. It's much faster to do a quick check
      for symbols first. Only do the full cmp when the symbols are exactly the
      same.
      
      The quick check is only to check symbols, not dso. Export
      _sort__sym_cmp.
      
        $ perf record --call-graph lbr ./tchain_edit_64
      
        Without the patch
        $time perf report --stdio
        real    0m21.142s
        user    0m21.110s
        sys     0m0.033s
      
        With the patch
        $time perf report --stdio
        real    0m10.977s
        user    0m10.948s
        sys     0m0.027s
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-18-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      12e89e65
    • K
      perf top: Add option to enable the LBR stitching approach · 13e0c844
      Kan Liang 提交于
      With the LBR stitching approach, the reconstructed LBR call stack
      can break the HW limitation. However, it may reconstruct invalid call
      stacks in some cases, e.g. exception handing such as setjmp/longjmp.
      Also, it may impact the processing time especially when the number of
      samples with stitched LBRs are huge.
      
      Add an option to enable the approach.
      The option must be used with --call-graph lbr.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-16-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      13e0c844
    • K
      perf callchain: Stitch LBR call stack · ff165628
      Kan Liang 提交于
      In LBR call stack mode, the depth of reconstructed LBR call stack limits
      to the number of LBR registers.
      
        For example, on skylake, the depth of reconstructed LBR call stack is
        always <= 32.
      
        # To display the perf.data header info, please use
        # --header/--header-only options.
        #
        #
        # Total Lost Samples: 0
        #
        # Samples: 6K of event 'cycles'
        # Event count (approx.): 6487119731
        #
        # Children      Self  Command          Shared Object       Symbol
        # ........  ........  ...............  ..................
        # ................................
      
          99.97%    99.97%  tchain_edit      tchain_edit        [.] f43
                  |
                   --99.64%--f11
                             f12
                             f13
                             f14
                             f15
                             f16
                             f17
                             f18
                             f19
                             f20
                             f21
                             f22
                             f23
                             f24
                             f25
                             f26
                             f27
                             f28
                             f29
                             f30
                             f31
                             f32
                             f33
                             f34
                             f35
                             f36
                             f37
                             f38
                             f39
                             f40
                             f41
                             f42
                             f43
      
      For a call stack which is deeper than LBR limit, HW will overwrite the
      LBR register with oldest branch. Only partial call stacks can be
      reconstructed.
      
      However, the overwritten LBRs may still be retrieved from previous
      sample. At that moment, HW hasn't overwritten the LBR registers yet.
      Perf tools can stitch those overwritten LBRs on current call stacks to
      get a more complete call stack.
      
      To determine if LBRs can be stitched, perf tools need to compare current
      sample with previous sample.
      
      - They should have identical LBR records (Same from, to and flags
        values, and the same physical index of LBR registers).
      
      - The searching starts from the base-of-stack of current sample.
      
      Once perf determines to stitch the previous LBRs, the corresponding LBR
      cursor nodes will be copied to 'lists'.  The 'lists' is to track the LBR
      cursor nodes which are going to be stitched.
      
      When the stitching is over, the nodes will not be freed immediately.
      They will be moved to 'free_lists'. Next stitching may reuse the space.
      Both 'lists' and 'free_lists' will be freed when all samples are
      processed.
      
      Committer notes:
      
      Fix the intel-pt.c initialization of the union with 'struct
      branch_flags', that breaks the build with its unnamed union on older gcc
      versions.
      
      Uninline thread__free_stitch_list(), as it grew big and started dragging
      includes to thread.h, so move it to thread.c where what it needs in
      terms of headers are already there.
      
      This fixes the build in several systems such as debian:experimental when
      cross building to the MIPS32 architecture, i.e. in the other cases what
      was needed was being included by sheer luck.
      
        In file included from builtin-sched.c:11:
        util/thread.h: In function 'thread__free_stitch_list':
        util/thread.h:169:3: error: implicit declaration of function 'free' [-Werror=implicit-function-declaration]
          169 |   free(pos);
              |   ^~~~
        util/thread.h:169:3: error: incompatible implicit declaration of built-in function 'free' [-Werror]
        util/thread.h:19:1: note: include '<stdlib.h>' or provide a declaration of 'free'
           18 | #include "callchain.h"
          +++ |+#include <stdlib.h>
           19 |
        util/thread.h:174:3: error: incompatible implicit declaration of built-in function 'free' [-Werror]
          174 |   free(pos);
              |   ^~~~
        util/thread.h:174:3: note: include '<stdlib.h>' or provide a declaration of 'free'
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-13-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ff165628
    • K
      perf callchain: Save previous cursor nodes for LBR stitching approach · 7f1d3931
      Kan Liang 提交于
      The cursor nodes which generates from sample are eventually added into
      callchain. To avoid generating cursor nodes from previous samples again,
      the previous cursor nodes are also saved for LBR stitching approach.
      
      Some option, e.g. hide-unresolved, may hide some LBRs.  Add a variable
      'valid' in struct callchain_cursor_node to indicate this case. The LBR
      stitching approach will only append the valid cursor nodes from previous
      samples later.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-12-kan.liang@linux.intel.com
      [ Use zfree() instead of open coded equivalent, and use it when freeing members of structs ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7f1d3931
    • K
      perf thread: Save previous sample for LBR stitching approach · 9c6c3f47
      Kan Liang 提交于
      To retrieve the overwritten LBRs from previous sample for LBR stitching
      approach, perf has to save the previous sample.
      
      Only allocate the struct lbr_stitch once, when LBR stitching approach is
      enabled and kernel supports hw_idx.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-11-kan.liang@linux.intel.com
      [ Use zalloc()/zfree() for thread->lbr_stitch ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9c6c3f47
    • K
      perf thread: Add a knob for LBR stitch approach · 771fd155
      Kan Liang 提交于
      The LBR stitch approach should be disabled by default. Because
      
      - The stitching approach base on LBR call stack technology. The known
        limitations of LBR call stack technology still apply to the approach,
        e.g. Exception handing such as setjmp/longjmp will have calls/returns
        not match.
      
      - This approach is not foolproof. There can be cases where it creates
        incorrect call stacks from incorrect matches. There is no attempt to
        validate any matches in another way.
      
      The 'lbr_stitch_enable' is used to indicate whether enable LBR stitch
      approach, which is disabled by default. The following patch will
      introduce a new option for each tools to enable the LBR stitch
      approach.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-10-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      771fd155
    • K
      perf machine: Factor out lbr_callchain_add_lbr_ip() · e2b23483
      Kan Liang 提交于
      Both caller and callee needs to add ip from LBR to callchain.
      Factor out lbr_callchain_add_lbr_ip() to improve code readability.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-9-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e2b23483
    • K
      perf machine: Factor out lbr_callchain_add_kernel_ip() · dd3e249a
      Kan Liang 提交于
      Both caller and callee needs to add kernel ip to callchain.  Factor out
      lbr_callchain_add_kernel_ip() to improve code readability.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-8-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd3e249a
    • K
      perf machine: Refine the function for LBR call stack reconstruction · e48b8311
      Kan Liang 提交于
      LBR only collect the user call stack. To reconstruct a call stack, both
      kernel call stack and user call stack are required. The function
      resolve_lbr_callchain_sample() mix the kernel call stack and user call
      stack.
      
      Now, with the help of HW idx, perf tool can reconstruct a more complete
      call stack by adding some user call stack from previous sample. However,
      current implementation is hard to be extended to support it.
      
      Current code path for resolve_lbr_callchain_sample()
      
        for (j = 0; j < mix_chain_nr; j++) {
             if (ORDER_CALLEE) {
                   if (kernel callchain)
                        Fill callchain info
                   else if (LBR callchain)
                        Fill callchain info
             } else {
                   if (LBR callchain)
                        Fill callchain info
                   else if (kernel callchain)
                        Fill callchain info
             }
             add_callchain_ip();
        }
      
      With the patch,
      
        if (ORDER_CALLEE) {
             for (j = 0; j < NUM of kernel callchain) {
                   Fill callchain info
                   add_callchain_ip();
             }
             for (; j < mix_chain_nr) {
                   Fill callchain info
                   add_callchain_ip();
             }
        } else {
             for (; j < NUM of LBR callchain) {
                   Fill callchain info
                   add_callchain_ip();
             }
             for (j = 0; j < mix_chain_nr) {
                   Fill callchain info
                   add_callchain_ip();
             }
        }
      
      No functional changes.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-7-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e48b8311
    • K
      perf machine: Remove the indent in resolve_lbr_callchain_sample · f8603267
      Kan Liang 提交于
      The indent is unnecessary in resolve_lbr_callchain_sample.  Removing it
      will make the following patch simpler.
      
      Current code path for resolve_lbr_callchain_sample()
      
              /* LBR only affects the user callchain */
              if (i != chain_nr) {
                      body of the function
                      ....
                      return 1;
              }
      
              return 0;
      
      With the patch,
      
              /* LBR only affects the user callchain */
              if (i == chain_nr)
                      return 0;
      
              body of the function
              ...
              return 1;
      
      No functional changes.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-6-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f8603267
    • K
      perf header: Support CPU PMU capabilities · 6f91ea28
      Kan Liang 提交于
      To stitch LBR call stack, the max LBR information is required. So the
      CPU PMU capabilities information has to be stored in perf header.
      
      Add a new feature HEADER_CPU_PMU_CAPS for CPU PMU capabilities.
      Retrieve all CPU PMU capabilities, not just max LBR information.
      
      Add variable max_branches to facilitate future usage.
      
      Committer testing:
      
        # ls -la /sys/devices/cpu/caps/
        total 0
        drwxr-xr-x. 2 root root    0 Apr 17 10:53 .
        drwxr-xr-x. 6 root root    0 Apr 17 07:02 ..
        -r--r--r--. 1 root root 4096 Apr 17 10:53 max_precise
        #
        # cat /sys/devices/cpu/caps/max_precise
        0
        # perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.033 MB perf.data (7 samples) ]
        #
        # perf report --header-only | egrep 'cpu(desc|.*capabilities)'
        # cpudesc : AMD Ryzen 5 3600X 6-Core Processor
        # cpu pmu capabilities: max_precise=0
        #
      
      And then on an Intel machine:
      
        $ ls -la /sys/devices/cpu/caps/
        total 0
        drwxr-xr-x. 2 root root    0 Apr 17 10:51 .
        drwxr-xr-x. 6 root root    0 Apr 17 10:04 ..
        -r--r--r--. 1 root root 4096 Apr 17 11:37 branches
        -r--r--r--. 1 root root 4096 Apr 17 10:51 max_precise
        -r--r--r--. 1 root root 4096 Apr 17 11:37 pmu_name
        $ cat /sys/devices/cpu/caps/max_precise
        3
        $ cat /sys/devices/cpu/caps/branches
        32
        $ cat /sys/devices/cpu/caps/pmu_name
        skylake
        $ perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
        $ perf report --header-only | egrep 'cpu(desc|.*capabilities)'
        # cpudesc : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
        # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake
        $
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-3-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6f91ea28
    • J
      perf parser: Add support to specify rXXX event with pmu · 3a6c51e4
      Jiri Olsa 提交于
      The current rXXXX event specification creates event under PERF_TYPE_RAW
      pmu type. This change allows to use rXXXX within pmu syntax, so it's
      type is used via the following syntax:
      
        -e 'cpu/r3c/'
        -e 'cpum_cf/r0/'
      
      The XXXX number goes directly to perf_event_attr::config the same way as
      in '-e rXXXX' event. The perf_event_attr::type is filled with pmu type.
      
      Committer testing:
      
      So, lets see what goes in perf_event_attr::config for, say, the
      'instructions' PERF_TYPE_HARDWARE (0) event, first we should look at how
      to encode this event as a PERF_TYPE_RAW event for this specific CPU, an
      AMD Ryzen 5:
      
        # cat /sys/devices/cpu/events/instructions
        event=0xc0
        #
      
      Then try with it _and_ the instruction, just to see that they are close
      enough:
      
        # perf stat -e rc0,instructions sleep 1
      
         Performance counter stats for 'sleep 1':
      
                   919,794      rc0
                   919,898      instructions
      
               1.000754579 seconds time elapsed
      
               0.000715000 seconds user
               0.000000000 seconds sys
        #
      
      Now we should try, before this patch, the PMU event encoding:
      
        # perf stat -e cpu/rc0/ sleep 1
        event syntax error: 'cpu/rc0/'
                                 \___ unknown term
      
        valid terms: event,edge,inv,umask,cmask,config,config1,config2,name,period,percore
        #
      
      Now with this patch, the three ways of specifying the 'instructions' CPU
      counter are accepted:
      
        # perf stat -e cpu/rc0/,rc0,instructions sleep 1
      
         Performance counter stats for 'sleep 1':
      
                   892,948      cpu/rc0/
                   893,052      rc0
                   893,156      instructions
      
               1.000931819 seconds time elapsed
      
               0.000916000 seconds user
               0.000000000 seconds sys
      
        #
      Requested-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NThomas Richter <tmricht@linux.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Link: http://lore.kernel.org/lkml/20200416221405.437788-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3a6c51e4
    • K
      perf pmu: Add support for PMU capabilities · 9fbc61f8
      Kan Liang 提交于
      The PMU capabilities information, which is located at
      /sys/bus/event_source/devices/<dev>/caps, is required by perf tool.  For
      example, the max LBR information is required to stitch LBR call stack.
      
      Add perf_pmu__caps_parse() to parse the PMU capabilities information.
      The information is stored in a list.
      
      The following patch will store the capabilities information in perf
      header.
      
      Committer notes:
      
      Here's an example of such directories and its files in an i5 7th gen
      machine:
      
        [root@seventh ~]# ls -lad /sys/bus/event_source/devices/*/caps
        drwxr-xr-x. 2 root root 0 Apr 14 13:33 /sys/bus/event_source/devices/cpu/caps
        drwxr-xr-x. 2 root root 0 Apr 14 13:33 /sys/bus/event_source/devices/intel_pt/caps
        [root@seventh ~]# ls -la /sys/bus/event_source/devices/intel_pt/caps
        total 0
        drwxr-xr-x. 2 root root    0 Apr 14 13:33 .
        drwxr-xr-x. 5 root root    0 Apr 14 13:12 ..
        -r--r--r--. 1 root root 4096 Apr 16 13:10 cr3_filtering
        -r--r--r--. 1 root root 4096 Apr 16 11:42 cycle_thresholds
        -r--r--r--. 1 root root 4096 Apr 16 13:10 ip_filtering
        -r--r--r--. 1 root root 4096 Apr 16 13:10 max_subleaf
        -r--r--r--. 1 root root 4096 Apr 14 13:33 mtc
        -r--r--r--. 1 root root 4096 Apr 14 13:33 mtc_periods
        -r--r--r--. 1 root root 4096 Apr 16 13:10 num_address_ranges
        -r--r--r--. 1 root root 4096 Apr 16 13:10 output_subsys
        -r--r--r--. 1 root root 4096 Apr 16 13:10 payloads_lip
        -r--r--r--. 1 root root 4096 Apr 16 13:10 power_event_trace
        -r--r--r--. 1 root root 4096 Apr 14 13:33 psb_cyc
        -r--r--r--. 1 root root 4096 Apr 14 13:33 psb_periods
        -r--r--r--. 1 root root 4096 Apr 16 13:10 ptwrite
        -r--r--r--. 1 root root 4096 Apr 16 13:10 single_range_output
        -r--r--r--. 1 root root 4096 Apr 16 12:03 topa_multiple_entries
        -r--r--r--. 1 root root 4096 Apr 16 13:10 topa_output
        [root@seventh ~]# cat /sys/bus/event_source/devices/intel_pt/caps/topa_output
        1
        [root@seventh ~]# cat /sys/bus/event_source/devices/intel_pt/caps/topa_multiple_entries
        1
        [root@seventh ~]# cat /sys/bus/event_source/devices/intel_pt/caps/mtc
        1
        [root@seventh ~]# cat /sys/bus/event_source/devices/intel_pt/caps/power_event_trace
        0
        [root@seventh ~]#
      
        [root@seventh ~]# ls -la /sys/bus/event_source/devices/cpu/caps/
        total 0
        drwxr-xr-x. 2 root root    0 Apr 14 13:33 .
        drwxr-xr-x. 6 root root    0 Apr 14 13:12 ..
        -r--r--r--. 1 root root 4096 Apr 16 13:10 branches
        -r--r--r--. 1 root root 4096 Apr 14 13:33 max_precise
        -r--r--r--. 1 root root 4096 Apr 16 13:10 pmu_name
        [root@seventh ~]# cat /sys/bus/event_source/devices/cpu/caps/max_precise
        3
        [root@seventh ~]# cat /sys/bus/event_source/devices/cpu/caps/branches
        32
        [root@seventh ~]# cat /sys/bus/event_source/devices/cpu/caps/pmu_name
        skylake
        [root@seventh ~]#
      
      Wow, first time I've heard about
      /sys/bus/event_source/devices/cpu/caps/max_precise, I think I'll use it!
      :-)
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200319202517.23423-2-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9fbc61f8
    • S
      perf stat: Force error in fallback on :k events · bec49a9e
      Stephane Eranian 提交于
      When it is not possible for a non-privilege perf command to monitor at
      the kernel level (:k), the fallback code forces a :u. That works if the
      event was previously monitoring both levels.  But if the event was
      already constrained to kernel only, then it does not make sense to
      restrict it to user only.
      
      Given the code works by exclusion, a kernel only event would have:
      
        attr->exclude_user = 1
      
      The fallback code would add:
      
        attr->exclude_kernel = 1
      
      In the end the end would not monitor in either the user level or kernel
      level. In other words, it would count nothing.
      
      An event programmed to monitor kernel only cannot be switched to user
      only without seriously warning the user.
      
      This patch forces an error in this case to make it clear the request
      cannot really be satisfied.
      
      Behavior with paranoid 1:
      
        $ sudo bash -c "echo 1 > /proc/sys/kernel/perf_event_paranoid"
        $ perf stat -e cycles:k sleep 1
      
         Performance counter stats for 'sleep 1':
      
                 1,520,413      cycles:k
      
               1.002361664 seconds time elapsed
      
               0.002480000 seconds user
               0.000000000 seconds sys
      
      Old behavior with paranoid 2:
      
        $ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
        $ perf stat -e cycles:k sleep 1
         Performance counter stats for 'sleep 1':
      
                         0      cycles:ku
      
               1.002358127 seconds time elapsed
      
               0.002384000 seconds user
               0.000000000 seconds sys
      
      New behavior with paranoid 2:
      
        $ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
        $ perf stat -e cycles:k sleep 1
        Error:
        You may not have permission to collect stats.
      
        Consider tweaking /proc/sys/kernel/perf_event_paranoid,
        which controls use of the performance events system by
        unprivileged users (without CAP_PERFMON or CAP_SYS_ADMIN).
      
        The current value is 2:
      
          -1: Allow use of (almost) all events by all users
              Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
        >= 0: Disallow ftrace function tracepoint by users without CAP_PERFMON or CAP_SYS_ADMIN
              Disallow raw tracepoint access by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN
        >= 1: Disallow CPU event access by users without CAP_PERFMON or CAP_SYS_ADMIN
        >= 2: Disallow kernel profiling by users without CAP_PERFMON or CAP_SYS_ADMIN
      
        To make this setting permanent, edit /etc/sysctl.conf too, e.g.:
      
                kernel.perf_event_paranoid = -1
      
      v2 of this patch addresses the review feedback from jolsa@redhat.com.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Reviewed-by: NIan Rogers <irogers@google.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20200414161550.225588-1-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bec49a9e
    • A
      perf tools: Add support for leader-sampling with AUX area events · e3459979
      Adrian Hunter 提交于
      When AUX area events are used in sampling mode, they must be the group
      leader, but the group leader is also used for leader-sampling. However,
      it is not desirable to use an AUX area event as the leader for
      leader-sampling, because it doesn't have any samples of its own. To support
      leader-sampling with AUX area events, use the 2nd event of the group as the
      "leader" for the purposes of leader-sampling.
      
      Example:
      
       # perf record --kcore --aux-sample -e '{intel_pt//,cycles,instructions}:S' -c 10000 uname
       [ perf record: Woken up 3 times to write data ]
       [ perf record: Captured and wrote 0.786 MB perf.data ]
       # perf report
       Samples: 380  of events 'anon group { cycles, instructions }', Event count (approx.): 3026164
                 Children              Self  Command  Shared Object      Symbol
       +   38.76%  42.65%     0.00%   0.00%  uname    [kernel.kallsyms]  [k] __x86_indirect_thunk_rax
       +   35.82%  31.33%     0.00%   0.00%  uname    ld-2.28.so         [.] _dl_start_user
       +   34.29%  29.74%     0.55%   0.47%  uname    ld-2.28.so         [.] _dl_start
       +   33.73%  28.62%     1.60%   0.97%  uname    ld-2.28.so         [.] dl_main
       +   33.19%  29.04%     0.52%   0.32%  uname    ld-2.28.so         [.] _dl_sysdep_start
       +   27.83%  33.74%     0.00%   0.00%  uname    [kernel.kallsyms]  [k] do_syscall_64
       +   26.76%  33.29%     0.00%   0.00%  uname    [kernel.kallsyms]  [k] entry_SYSCALL_64_after_hwframe
       +   23.78%  20.33%     5.97%   5.25%  uname    [kernel.kallsyms]  [k] page_fault
       +   23.18%  24.60%     0.00%   0.00%  uname    libc-2.28.so       [.] __libc_start_main
       +   22.64%  24.37%     0.00%   0.00%  uname    uname              [.] _start
       +   21.04%  23.27%     0.00%   0.00%  uname    uname              [.] main
       +   19.48%  18.08%     3.72%   3.64%  uname    ld-2.28.so         [.] _dl_relocate_object
       +   19.47%  21.81%     0.00%   0.00%  uname    libc-2.28.so       [.] setlocale
       +   19.44%  21.56%     0.52%   0.61%  uname    libc-2.28.so       [.] _nl_find_locale
       +   17.87%  19.66%     0.00%   0.00%  uname    libc-2.28.so       [.] _nl_load_locale_from_archive
       +   15.71%  13.73%     0.53%   0.52%  uname    [kernel.kallsyms]  [k] do_page_fault
       +   15.18%  13.21%     1.03%   0.68%  uname    [kernel.kallsyms]  [k] handle_mm_fault
       +   14.15%  12.53%     1.01%   1.12%  uname    [kernel.kallsyms]  [k] __handle_mm_fault
       +   12.03%   9.67%     0.54%   0.32%  uname    ld-2.28.so         [.] _dl_map_object
       +   10.55%   8.48%     0.00%   0.00%  uname    ld-2.28.so         [.] openaux
       +   10.55%  20.20%     0.52%   0.61%  uname    libc-2.28.so       [.] __run_exit_handlers
      
      Comnmitter notes:
      
      Fixed up this problem:
      
        util/record.c: In function ‘perf_evlist__config’:
        util/record.c:256:3: error: too few arguments to function ‘perf_evsel__config_leader_sampling’
          256 |   perf_evsel__config_leader_sampling(evsel);
              |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        util/record.c:190:13: note: declared here
          190 | static void perf_evsel__config_leader_sampling(struct evsel *evsel,
              |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20200401101613.6201-17-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e3459979
    • A
      perf evlist: Allow multiple read formats · 94d3820f
      Adrian Hunter 提交于
      Tools find the correct evsel, and therefore read format, using the event
      ID, so it isn't necessary for all read formats to be the same. In the
      case of leader-sampling of AUX area events, dummy tracking events will
      have a different read format, so relax the validation to become a debug
      message only.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20200401101613.6201-16-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      94d3820f
    • A
      perf evsel: Rearrange perf_evsel__config_leader_sampling() · 3713eb37
      Adrian Hunter 提交于
      In preparation for adding support for leader sampling with AUX area events.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20200401101613.6201-15-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3713eb37
    • A
      perf evlist: Move leader-sampling configuration · 5f342788
      Adrian Hunter 提交于
      Move leader-sampling configuration in preparation for adding support for
      leader sampling with AUX area events.
      
      Committer notes:
      
      It only makes sense when configuring an evsel that is part of an evlist,
      so the only case where it is called outside perf_evlist__config(), in
      some 'perf test' entry, is safe, and even there we should just use
      perf_evlist__config(), but since in that case we have just one evsel in
      the evlist, it is equivalent.
      
      Also fixed up this problem:
      
        util/record.c: In function ‘perf_evlist__config’:
        util/record.c:223:3: error: too many arguments to function ‘perf_evsel__config_leader_sampling’
          223 |   perf_evsel__config_leader_sampling(evsel, evlist);
              |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        util/record.c:170:13: note: declared here
          170 | static void perf_evsel__config_leader_sampling(struct evsel *evsel)
              |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20200401101613.6201-14-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5f342788
新手
引导
客服 返回
顶部