1. 06 6月, 2018 2 次提交
    • A
      perf hists: Check if a hist_entry has callchains before using them · fabd37b8
      Arnaldo Carvalho de Melo 提交于
      So far if we use 'perf record -g' this will make
      symbol_conf.use_callchain 'true' and logic will assume that all events
      have callchains enabled, but ever since we added the possibility of
      setting up callchains for some events (e.g.: -e
      cycles/call-graph=dwarf/) while not for others, we limit usage scenarios
      by looking at that symbol_conf.use_callchain global boolean, we better
      look at each event attributes.
      
      On the road to that we need to look if a hist_entry has callchains, that
      is, to go from hist_entry->hists to the evsel that contains it, to then
      look at evsel->sample_type for PERF_SAMPLE_CALLCHAIN.
      
      The next step is to add a symbol_conf.ignore_callchains global, to use
      in the places where what we really want to know is if callchains should
      be ignored, even if present.
      
      Then -g will mean just to select a callchain mode to be applied to all
      events not explicitely setting some other callchain mode, i.e. a default
      callchain mode, and --no-call-graph will set
      symbol_conf.ignore_callchains with that clear intention.
      
      That too will at some point become a per evsel thing, that tools can set
      for all or just a few of its evsels.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-0sas5cm4dsw2obn75g7ruz69@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fabd37b8
    • A
      perf hists: Introduce hist_entry__has_callchain() method · 0b5d6ece
      Arnaldo Carvalho de Melo 提交于
      We'll use this helper more frequently when reworking
      symbol_conf.use_callchain logic, where knowing if a hist_entry has
      callchains is the important bit, so make going from hist_entry to hists
      to evsel easier, compact.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-p6gioxkzpkpz71dtt4wcs36o@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0b5d6ece
  2. 05 6月, 2018 1 次提交
  3. 04 6月, 2018 25 次提交
  4. 02 6月, 2018 1 次提交
  5. 31 5月, 2018 3 次提交
  6. 30 5月, 2018 1 次提交
    • K
      perf parse-events: Handle uncore event aliases in small groups properly · 369b2308
      Kan Liang 提交于
      Perf stat doesn't count the uncore event aliases from the same uncore
      block in a group, for example:
      
        perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000
        #           time             counts unit events
             1.000447342      <not counted>      unc_m_cas_count.all
             1.000447342      <not counted>      unc_m_clockticks
             2.000740654      <not counted>      unc_m_cas_count.all
             2.000740654      <not counted>      unc_m_clockticks
      
      The output is very misleading. It gives a wrong impression that the
      uncore event doesn't work.
      
      An uncore block could be composed by several PMUs. An uncore event alias
      is a joint name which means the same event runs on all PMUs of a block.
      Perf doesn't support mixed events from different PMUs in the same group.
      It is wrong to put uncore event aliases in a big group.
      
      The right way is to split the big group into multiple small groups which
      only include the events from the same PMU.
      
      Only uncore event aliases from the same uncore block should be specially
      handled here. It doesn't make sense to mix the uncore events with other
      uncore events from different blocks or even core events in a group.
      
      With the patch:
        #           time             counts unit events
           1.001557653            140,833      unc_m_cas_count.all
           1.001557653      1,330,231,332      unc_m_clockticks
           2.002709483             85,007      unc_m_cas_count.all
           2.002709483      1,429,494,563      unc_m_clockticks
      Reported-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Agustin Vega-Frias <agustinv@codeaurora.org>
      Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: http://lkml.kernel.org/r/1525727623-19768-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      369b2308
  7. 23 5月, 2018 7 次提交
新手
引导
客服 返回
顶部