1. 08 Feb, 2021 5 commits
    • Kan Liang's avatar
      perf tools: Support data block and addr block · a054c298
      Kan Liang authored
      Two new data source fields, to indicate the block reasons of a load
      instruction, are introduced on the Intel Sapphire Rapids server. The
      fields can be used by the memory profiling.
      
      Add a new sort function, SORT_MEM_BLOCKED, for the two fields.
      
      For the previous platforms or the block reason is unknown, print "N/A"
      for the block reason.
      
      Add blocked as a default mem sort key for perf report and perf mem
      report.
      
      Committer testing:
      
      So in machines without this capability we get a "N/A" filling the new "Blocked"
      column:
      
        $ perf mem record ls
        arch     certs	 CREDITS  Documentation  include  ipc     Kconfig  lib       MAINTAINERS  mm   samples  security  usr    block
        COPYING	 crypto	 drivers  fs             init     Kbuild  kernel   LICENSES  Makefile     net  README   scripts   sound  tools
        virt
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.008 MB perf.data (17 samples) ]
        $
        $ perf mem report --stdio
        # To display the perf.data header info, please use --header/--header-only options.
        #
        # Total Lost Samples: 0
        #
        # Samples: 6  of event 'cpu/mem-loads,ldlat=30/Pu'
        # Total weight : 1381
        # Sort order   : local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked,blocked
        #
        # Overhead  Samples  Local Weight  Memory access         Symbol                   Shared Object  Data Symbol             Data Object   Snoop  TLB access    Locked  Blocked
        # ........  .......  ............  ....................  .......................  .............  ......................  ............  .....  ............  ......  .......
        #
            32.87%        1  454           Local RAM or RAM hit  [.] _dl_relocate_object  ld-2.31.so     [.] 0x00007fe91cef3078  libc-2.31.so  Hit    L1 or L2 hit  No       N/A
            25.56%        1  353           LFB or LFB hit        [.] strcmp               ld-2.31.so     [.] 0x00005586973855ca  ls            None   L1 or L2 hit  No       N/A
            22.59%        1  312           LFB or LFB hit        [.] _dl_cache_libcmp     ld-2.31.so     [.] 0x00007fe91d0e3b18  ld.so.cache   None   L1 or L2 hit  No       N/A
             8.47%        1  117           LFB or LFB hit        [.] _dl_relocate_object  ld-2.31.so     [.] 0x00007fe91ceee570  libc-2.31.so  None   L1 or L2 hit  No       N/A
             6.88%        1  95            LFB or LFB hit        [.] _dl_relocate_object  ld-2.31.so     [.] 0x00007fe91ceed490  libc-2.31.so  None   L1 or L2 hit  No       N/A
             3.62%        1  50            LFB or LFB hit        [.] _dl_cache_libcmp     ld-2.31.so     [.] 0x00007fe91d0ebe60  ld.so.cache   None   L1 or L2 hit  No       N/A
      
        # Samples: 11  of event 'cpu/mem-stores/Pu'
        # Total weight : 11
        # Sort order   : local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked,blocked
        #
        # Overhead  Samples  Local Weight  Memory access  Symbol                   Shared Object  Data Symbol             Data Object  Snoop  TLB access  Locked  Blocked
        # ........  .......  ............  .............  .......................  .............  ......................  ...........  .....  ..........  ......  .......
        #
             9.09%        1  0             L1 hit         [.] __strcoll_l          libc-2.31.so   [.] 0x00007fffe5648fc8  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] _dl_lookup_symbol_x  ld-2.31.so     [.] 0x00007fffe56490b8  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] _dl_name_match_p     ld-2.31.so     [.] 0x00007fffe56487d8  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] _dl_start            ld-2.31.so     [.] start_time+0x0      ld-2.31.so   N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] _dl_sysdep_start     ld-2.31.so     [.] 0x00007fffe56494b8  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] do_lookup_x          ld-2.31.so     [.] 0x00007fffe5648ff8  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] do_lookup_x          ld-2.31.so     [.] 0x00007fffe5649064  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 hit         [.] do_lookup_x          ld-2.31.so     [.] 0x00007fffe5649130  [stack]      N/A    N/A         N/A      N/A
             9.09%        1  0             L1 miss        [.] _dl_start            ld-2.31.so     [.] _rtld_global+0xaf8  ld-2.31.so   N/A    N/A         N/A      N/A
             9.09%        1  0             L1 miss        [.] _dl_start            ld-2.31.so     [.] _rtld_global+0xc28  ld-2.31.so   N/A    N/A         N/A      N/A
             9.09%        1  0             L1 miss        [.] _dl_start            ld-2.31.so     [.] 0x00007fffe56495b8  [stack]      N/A    N/A         N/A      N/A
      
        # (Tip: Show user configuration overrides: perf config --user --list)
        $
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/1612296553-21962-4-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a054c298
    • Kan Liang's avatar
      perf tools: Support the auxiliary event · 2a57d408
      Kan Liang authored
      On the Intel Sapphire Rapids server, an auxiliary event has to be
      enabled simultaneously with the load latency event to retrieve complete
      Memory Info.
      
      Add X86 specific perf_mem_events__name() to handle the auxiliary event.
      
      - Users are only interested in the samples of the mem-loads event.
        Sample read the auxiliary event.
      
      - The auxiliary event must be in front of the load latency event in a
        group. Assume the second event to sample if the auxiliary event is the
        leader.
      
      - Add a weak is_mem_loads_aux_event() to check the auxiliary event for
        X86. For other ARCHs, it always return false.
      
      Parse the unique event name, mem-loads-aux, for the auxiliary event.
      
      Committer notes:
      
      According to 61b985e3 ("perf/x86/intel: Add perf core PMU
      support for Sapphire Rapids"), ENODATA is only returned by
      sys_perf_event_open() when used with these auxiliary events, with this
      in evsel__open_strerror():
      
             case ENODATA:
                     return scnprintf(msg, size, "Cannot collect data source with the load latency event alone. "
                                      "Please add an auxiliary event in front of the load latency event.");
      
      This is Ok at this point in time, but fragile long term, I pointed this
      out in the e-mail thread, requesting a follow up patch to check if
      ENODATA is really for this specific case.
      
      Fixed up sizeof(MEM_LOADS_AUX_NAME) bug pointed out by Namhyung.
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/20210205152648.GC920417@kernel.org
      Link: http://lore.kernel.org/lkml/1612296553-21962-3-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2a57d408
    • Kan Liang's avatar
      tools headers uapi: Update tools's copy of linux/perf_event.h · 81898ef1
      Kan Liang authored
      To get the changes in these csets:
      
        2a6c6b7d ("perf/core: Add PERF_SAMPLE_WEIGHT_STRUCT")
        61b985e3 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids")
      
      This cures the following warning during perf's build:
      
              Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h' differs from latest version at 'include/uapi/linux/perf_event.h'
              diff -u tools/include/uapi/linux/perf_event.h include/uapi/linux/perf_event.h
      
      Committer notes:
      
      Picked by hand as I had already merged the MMAP buildid patch that also touches
      perf_event.h and is also only in {acme,tip}/perf/core, not yet upstream.
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/1612296553-21962-2-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      81898ef1
    • Athira Rajeev's avatar
      perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs · 068aeea3
      Athira Rajeev authored
      To enable presenting of Performance Monitor Counter Registers (PMC1 to
      PMC6) as part of extended regsiters, this patch adds these to
      sample_reg_mask in the tool side (to use with -I? option).
      
      Simplified the PERF_REG_PMU_MASK_300/31 definition. Excluded the
      unsupported SPRs (MMCR3, SIER2, SIER3) from extended mask value for
      CPU_FTR_ARCH_300.
      Signed-off-by: default avatarAthira Jajeev <atrajeev@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      068aeea3
    • Jianlin Lv's avatar
      perf probe: Add protection to avoid endless loop · 900547dd
      Jianlin Lv authored
      if dwarf_offdie() returns NULL, the continue statement forces the next
      iteration of the loop without updating the 'off' variable. It will cause
      an endless loop in the process of traversing the compile unit.  So add
      exception protection for looping CUs.
      Signed-off-by: default avatarJianlin Lv <Jianlin.Lv@arm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.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>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: jianlin.lv@arm.com
      Link: http://lore.kernel.org/lkml/20210203145702.1219509-1-Jianlin.Lv@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      900547dd
  2. 03 Feb, 2021 16 commits
    • Ian Rogers's avatar
      perf trace-event-info: Rename for_each_event. · d2e31d7e
      Ian Rogers authored
      Avoid a naming conflict with for_each_event with similar code in
      parse-events.c, rename to for_each_event_tps.
      Signed-off-by: default avatarIan Rogers <irogers@google.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>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/20210203052659.2975736-1-irogers@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d2e31d7e
    • Arnaldo Carvalho de Melo's avatar
    • Athira Rajeev's avatar
      perf powerpc: Fix gap between kernel end and module start · 557c3ead
      Athira Rajeev authored
      Running "perf mem report" in TUI mode fails with ENOMEM message in
      powerpc:
      
        failed to process sample
      
      Running with debug and verbose options points that issue is while
      allocating memory for sample histograms.
      
      The error path is:
      
        symbol__inc_addr_samples() ->
          __symbol__inc_addr_samples() ->
            annotated_source__histogram()
      
      symbol__inc_addr_samples() calls annotated_source__alloc_histograms ()
      to allocate memory for sample histograms using calloc(). Here calloc()
      fails since the size of symbol is huge. The size of a symbol is
      calculated as difference between its start and end address.
      
      Example histogram allocation that fails is:
      
        sym->name is _end
        sym->start is 0xc0000000027a0000
        sym->end is 0xc008000003890000
        symbol__size(sym) is 0x80000010f0000
      
      In the above case, the difference between sym->start
      (0xc0000000027a0000) and sym->end (0xc008000003890000) is huge.
      
      This is same problem as in s390 and arm64 which are fixed in commits:
      
        b9c0a649 ("perf annotate: Fix s390 gap between kernel end and module start")
        78886f3e ("perf symbols: Fix arm64 gap between kernel start and module end")
      
      When this symbol was read first, its start and end address was set to
      address which matches with data from /proc/kallsyms.
      
      After symbol__new():
      
        symbol__new: _end 0xc0000000027a0000-0xc0000000027a0000
      
        From /proc/kallsyms:
        ...
        c000000002799370 b backtrace_flag
        c000000002799378 B radix_tree_node_cachep
        c000000002799380 B __bss_stop
        c0000000027a0000 B _end
        c008000003890000 t icmp_checkentry      [ip_tables]
        c008000003890038 t ipt_alloc_initial_table      [ip_tables]
        c008000003890468 T ipt_do_table [ip_tables]
        c008000003890de8 T ipt_unregister_table_pre_exit        [ip_tables]
        ...
      
      Perf calls function symbols__fixup_end() which sets the end of symbol to
      0xc008000003890000, which is the next address and this is the start
      address of first module (icmp_checkentry in above) which will make the
      huge symbol size of 0x80000010f0000.
      
      After symbols__fixup_end:
      
        symbols__fixup_end: sym->name: _end
        sym->start: 0xc0000000027a0000
        sym->end: 0xc008000003890000
      
      On powerpc, kernel text segment is located at 0xc000000000000000 whereas
      the modules are located at very high memory addresses,
      0xc00800000xxxxxxx. Since the gap between end of kernel text segment and
      beginning of first module's address is high, histogram allocation using
      calloc fails.
      
      Fix this by detecting the kernel's last symbol and limiting the range of
      last kernel symbol to pagesize.
      
      Signed-off-by: Athira Rajeev<atrajeev@linux.vnet.ibm.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Tested-By: default avatarKajol Jain <kjain@linux.ibm.com>
      Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/1609208054-1566-1-git-send-email-atrajeev@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      557c3ead
    • Yonatan Goldschmidt's avatar
      perf inject jit: Add namespaces support · 67dec926
      Yonatan Goldschmidt authored
      This patch fixes "perf inject --jit" to properly operate on
      namespaced/containerized processes:
      
      * jitdump files are generated by the process, thus they should be
        looked up in its mount NS.
      
      * DSOs of injected MMAP events will later be looked up in the process
        mount NS, so write them into its NS.
      
      * PIDs & TIDs from jitdump events need to be translated to the PID as
        seen by "perf record" before written into MMAP events.
      
      For a process in a different PID NS, the TID & PID given in the jitdump
      event are actually ignored; I use the TID & PID of the thread which
      mmap()ed the jitdump file. This is simplified and won't do for forks of
      the initial process, if they continue using the same jitdump file.
      Future patches might improve it.
      
      This was tested by recording a NodeJS process running with
      "--perf-prof", inside a Docker container, and by recording another
      NodeJS process running in the same namespaces as perf itself, to make
      sure it's not broken for non-containerized processes.
      Signed-off-by: default avatarYonatan Goldschmidt <yonatan.goldschmidt@granulate.io>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20201105015604.1726943-1-yonatan.goldschmidt@granulate.ioSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      67dec926
    • Yonatan Goldschmidt's avatar
      perf namespaces: Add 'in_pidns' to nsinfo struct · 2b51c71b
      Yonatan Goldschmidt authored
      Provides an accurate mean to determine if the owner thread is in a
      different PID namespace.
      Signed-off-by: default avatarYonatan Goldschmidt <yonatan.goldschmidt@granulate.io>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20201105015418.1725218-1-yonatan.goldschmidt@granulate.ioSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2b51c71b
    • Namhyung Kim's avatar
      perf tools: Use scandir() to iterate threads when synthesizing PERF_RECORD_ events · 473f742e
      Namhyung Kim authored
      Like in __event__synthesize_thread(), I think it's better to use
      scandir() instead of the readdir() loop.  In case some malicious task
      continues to create new threads, the readdir() loop will run over and
      over to collect tids.  The scandir() also has the problem but the window
      is much smaller since it doesn't do much work during the iteration.
      
      Also add filter_task() function as we only care the tasks.
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20210202090118.2008551-4-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      473f742e
    • Namhyung Kim's avatar
      perf tools: Skip PERF_RECORD_MMAP event synthesis for kernel threads · c1b90795
      Namhyung Kim authored
      To synthesize information to resolve sample IPs, it needs to scan task
      and mmap info from the /proc filesystem.  For each process, it opens
      (and reads) status and maps file respectively.  But as kernel threads
      don't have memory maps so we can skip the maps file.
      
      To find kernel threads, check "VmPeak:" line in /proc/<PID>/status file.
      It's about the peak virtual memory usage so only user-level tasks have
      that.  Note that it's possible to miss the line due to partial reads.
      So we should double-check if it's a really kernel thread when there's no
      VmPeak line.
      
      Thus check "Threads:" line (which follows the VmPeak line whether or not
      it exists) to be sure it's read enough data - just in case of deeply
      nested pid namespaces or large number of supplementary groups are
      involved.
      
      This is for user process:
      
        $ head -40 /proc/1/status
        Name:	systemd
        Umask:	0000
        State:	S (sleeping)
        Tgid:	1
        Ngid:	0
        Pid:	1
        PPid:	0
        TracerPid:	0
        Uid:	0	0	0	0
        Gid:	0	0	0	0
        FDSize:	256
        Groups:
        NStgid:	1
        NSpid:	1
        NSpgid:	1
        NSsid:	1
        VmPeak:	  234192 kB           <-- here
        VmSize:	  169964 kB
        VmLck:	       0 kB
        VmPin:	       0 kB
        VmHWM:	   29528 kB
        VmRSS:	    6104 kB
        RssAnon:	    2756 kB
        RssFile:	    3348 kB
        RssShmem:	       0 kB
        VmData:	   19776 kB
        VmStk:	    1036 kB
        VmExe:	     784 kB
        VmLib:	    9532 kB
        VmPTE:	     116 kB
        VmSwap:	    2400 kB
        HugetlbPages:	       0 kB
        CoreDumping:	0
        THP_enabled:	1
        Threads:	1                     <-- and here
        SigQ:	1/62808
        SigPnd:	0000000000000000
        ShdPnd:	0000000000000000
        SigBlk:	7be3c0fe28014a03
        SigIgn:	0000000000001000
      
      And this is for kernel thread:
      
        $ head -20 /proc/2/status
        Name:	kthreadd
        Umask:	0000
        State:	S (sleeping)
        Tgid:	2
        Ngid:	0
        Pid:	2
        PPid:	0
        TracerPid:	0
        Uid:	0	0	0	0
        Gid:	0	0	0	0
        FDSize:	64
        Groups:
        NStgid:	2
        NSpid:	2
        NSpgid:	0
        NSsid:	0
        Threads:	1                     <-- here
        SigQ:	1/62808
        SigPnd:	0000000000000000
        ShdPnd:	0000000000000000
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20210202090118.2008551-3-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c1b90795
    • Namhyung Kim's avatar
      perf tools: Use /proc/<PID>/task/<TID>/status for PERF_RECORD_ event synthesis · 30626e08
      Namhyung Kim authored
      To save memory usage, it needs to reduce the number of entries in the
      proc filesystem.  It's using /proc/<PID>/task directory to traverse
      threads in the process and then kernel creates /proc/<PID>/task/<TID>
      entries.
      
      After that it checks the thread info using the /proc/<TID>/status file
      rather than /proc/<PID>/task/<TID>/status.  As far as I can see, they
      are the same and contain all the info we need.
      
      Using the latter eliminates the unnecessary /proc/<TID> entry.  This can
      be useful especially a large number of threads are used in the system.
      In my experiment around 1KB of memory on average was saved for each
      thread (which is not a thread group leader).
      
      To do this, pass both pid and tid to perf_event_prepare_comm() if it
      knows them.  In case it doesn't know, passing 0 as pid will do the old
      way.
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20210202090118.2008551-2-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      30626e08
    • John Garry's avatar
      perf vendor events arm64: Reference common and uarch events for A76 · c3a9cdef
      John Garry authored
      Reduce duplication in the JSONs by referencing standard events from
      armv8-common-and-microarch.json
      
      In general the "PublicDescription" fields are not modified when somewhat
      significantly worded differently than the standard.
      
      Apart from that, description and names for events slightly different to
      standard are changed (to standard) for consistency.
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Nakamura, Shunsuke/中村 俊介 <nakamura.shun@fujitsu.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@openeuler.org
      Link: https://lore.kernel.org/r/1611835236-34696-5-git-send-email-john.garry@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c3a9cdef
    • John Garry's avatar
      perf vendor events arm64: Reference common and uarch events for Ampere eMag · d02d5dc8
      John Garry authored
      Reduce duplication in the JSONs by referencing standard events from
      armv8-common-and-microarch.json
      
      In general the "PublicDescription" fields are not modified when somewhat
      significantly worded differently than the standard.
      
      Apart from that, description and names for events slightly different to
      standard are changed (to standard) for consistency.
      
      Note that names for events 0x34 and 0x35 are non-standard and remain
      unchanged. Those events came from the following originally:
      
        https://github.com/AmpereComputing/ampere-centos-kernel/blob/4c2479c67bbcf35b35224db12a092b33682b181c/Documentation/arm64/eMAG-ARM-CoreImpDefined.pdfSigned-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Nakamura, Shunsuke/中村 俊介 <nakamura.shun@fujitsu.com>
      Cc: mathieu.poirier@linaro.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@openeuler.org
      Link: https://lore.kernel.org/r/1611835236-34696-4-git-send-email-john.garry@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d02d5dc8
    • John Garry's avatar
      perf vendor events arm64: Add common and uarch event JSON · c7766966
      John Garry authored
      Add a common and microarch JSON, which can be referenced from CPU JSONs.
      
      For now, brief and public description are as event brief event
      description from the ARMv8 ARM [0], D7-11.
      
      The list of events is not complete, as not all events will be referenced
      yet.
      
      Reference document is at the following:
      
      [0] https://documentation-service.arm.com/static/5fa3bd1eb209f547eebd4141?token=Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Nakamura, Shunsuke/中村 俊介 <nakamura.shun@fujitsu.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@openeuler.org
      Link: https://lore.kernel.org/r/1611835236-34696-3-git-send-email-john.garry@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c7766966
    • John Garry's avatar
      perf vendor events arm64: Fix Ampere eMag event typo · 2bf797be
      John Garry authored
      The "briefdescription" for event 0x35 has a typo - fix it.
      
      Fixes: d35c595b ("perf vendor events arm64: Revise core JSON events for eMAG")
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Nakamura, Shunsuke/中村 俊介 <nakamura.shun@fujitsu.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@openeuler.org
      Link: https://lore.kernel.org/r/1611835236-34696-2-git-send-email-john.garry@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2bf797be
    • Jin Yao's avatar
      perf script: Support DSO filter like in other perf tools · 4b799a9b
      Jin Yao authored
      Other perf tool builtins already supported a DSO filter.
      
      For example:
      
        $ perf report --dsos a,b,c
      
      which only considers symbols in these dsos.
      
      Now the DSO filter is supported in 'perf script':
      
        root@kbl-ppc:~# ./perf script --dsos "[kernel.kallsyms]"
                  perf 18123 [000] 6142863.075104:          1   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
                  perf 18123 [000] 6142863.075107:          1   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
                  perf 18123 [000] 6142863.075108:         10   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
                  perf 18123 [000] 6142863.075109:        273   cycles:  ffffffff9ca7730a native_write_msr+0xa ([kernel.kallsyms])
                  perf 18123 [000] 6142863.075110:       7684   cycles:  ffffffff9ca3c9c0 native_sched_clock+0x50 ([kernel.kallsyms])
                  perf 18123 [000] 6142863.075112:     213017   cycles:  ffffffff9d765a92 syscall_exit_to_user_mode+0x32 ([kernel.kallsyms])
                  perf 18123 [001] 6142863.075156:          1   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
                  perf 18123 [001] 6142863.075158:          1   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
                  perf 18123 [001] 6142863.075159:         17   cycles:  ffffffff9ca77308 native_write_msr+0x8 ([kernel.kallsyms])
      
      Committer testing:
      
        $ perf script
                      ls 2364888 29303.010949:          1 cycles:u:  ffffffffa4bbc6a9 [unknown] ([unknown])
                      ls 2364888 29303.010957:          1 cycles:u:  ffffffffa429ef48 [unknown] ([unknown])
                      ls 2364888 29303.010961:          1 cycles:u:  ffffffffa4260133 [unknown] ([unknown])
                      ls 2364888 29303.010964:          5 cycles:u:  ffffffffa429efad [unknown] ([unknown])
                      ls 2364888 29303.010967:         41 cycles:u:  ffffffffa42a4586 [unknown] ([unknown])
                      ls 2364888 29303.010972:        435 cycles:u:  ffffffffa429efe0 [unknown] ([unknown])
                      ls 2364888 29303.010978:       5142 cycles:u:      7f9b95bc2abf __GI___tunables_init+0x11f (/usr/lib64/ld-2.32.so)
                      ls 2364888 29303.011006:      38551 cycles:u:  ffffffffa4290f61 [unknown] ([unknown])
                      ls 2364888 29303.011486:     238234 cycles:u:      7f9b95bb7741 _dl_relocate_object+0xa71 (/usr/lib64/ld-2.32.so)
                      ls 2364888 29303.011937:     415870 cycles:u:      7f9b95a1c80e __strcoll_l+0xe (/usr/lib64/libc-2.32.so)
        $
      
      Before:
      
        $ perf script --dsos /usr/lib64/libc-2.32.so |& head -5
          Error: unknown option `dsos'
      
         Usage: perf script [<options>]
            or: perf script [<options>] record <script> [<record-options>] <command>
            or: perf script [<options>] report <script> [script-args]
        $
      
      After:
      
        $ perf script --dsos /usr/lib64/libc-2.32.so
                      ls 2364888 29303.011937:     415870 cycles:u:      7f9b95a1c80e __strcoll_l+0xe (/usr/lib64/libc-2.32.so)
        $
      Signed-off-by: default avatarJin Yao <yao.jin@linux.intel.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20210124232750.19170-2-yao.jin@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      4b799a9b
    • Arnaldo Carvalho de Melo's avatar
      perf tools: Fix DSO filtering when not finding a map for a sampled address · c69bf11a
      Arnaldo Carvalho de Melo authored
      When we lookup an address and don't find a map we should filter that
      sample if the user specified a list of --dso entries to filter on, fix
      it.
      
      Before:
      
        $ perf script
                   sleep 274800  2843.556162:          1 cycles:u:  ffffffffbb26bff4 [unknown] ([unknown])
                   sleep 274800  2843.556168:          1 cycles:u:  ffffffffbb2b047d [unknown] ([unknown])
                   sleep 274800  2843.556171:          1 cycles:u:  ffffffffbb2706b2 [unknown] ([unknown])
                   sleep 274800  2843.556174:          6 cycles:u:  ffffffffbb2b0267 [unknown] ([unknown])
                   sleep 274800  2843.556176:         59 cycles:u:  ffffffffbb2b03b1 [unknown] ([unknown])
                   sleep 274800  2843.556180:        691 cycles:u:  ffffffffbb26bff4 [unknown] ([unknown])
                   sleep 274800  2843.556189:       9160 cycles:u:      7fa9550eeaa3 __GI___tunables_init+0xf3 (/usr/lib64/ld-2.32.so)
                   sleep 274800  2843.556312:      86937 cycles:u:      7fa9550e157b _dl_lookup_symbol_x+0x4b (/usr/lib64/ld-2.32.so)
        $
      
      So we have some samples we somehow didn't find in a map for, if we now
      do:
      
        $ perf report --stdio --dso /usr/lib64/ld-2.32.so
        # dso: /usr/lib64/ld-2.32.so
        #
        # Total Lost Samples: 0
        #
        # Samples: 8  of event 'cycles:u'
        # Event count (approx.): 96856
        #
        # Overhead  Command  Symbol
        # ........  .......  ........................
        #
            89.76%  sleep    [.] _dl_lookup_symbol_x
             9.46%  sleep    [.] __GI___tunables_init
             0.71%  sleep    [k] 0xffffffffbb26bff4
             0.06%  sleep    [k] 0xffffffffbb2b03b1
             0.01%  sleep    [k] 0xffffffffbb2b0267
             0.00%  sleep    [k] 0xffffffffbb2706b2
             0.00%  sleep    [k] 0xffffffffbb2b047d
        $
      
      After this patch we get the right output with just entries for the DSOs
      specified in --dso:
      
        $ perf report --stdio --dso /usr/lib64/ld-2.32.so
        # dso: /usr/lib64/ld-2.32.so
        #
        # Total Lost Samples: 0
        #
        # Samples: 8  of event 'cycles:u'
        # Event count (approx.): 96856
        #
        # Overhead  Command  Symbol
        # ........  .......  ........................
        #
            89.76%  sleep    [.] _dl_lookup_symbol_x
             9.46%  sleep    [.] __GI___tunables_init
        $
        #
      
      Fixes: 96415e4d ("perf symbols: Avoid unnecessary symbol loading when dso list is specified")
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20210128131209.GD775562@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c69bf11a
    • Kan Liang's avatar
      perf stat: Add Topdown metrics events as default events · 42641d6f
      Kan Liang authored
      The Topdown Microarchitecture Analysis (TMA) Method is a structured
      analysis methodology to identify critical performance bottlenecks in
      out-of-order processors. From the Ice Lake and later platforms, the
      Topdown information can be retrieved from the dedicated "metrics"
      register, which isn't impacted by other events. Also, the Topdown
      metrics support both per thread/process and per core measuring.  Adding
      Topdown metrics events as default events can enrich the default
      measuring information, and would not cost any extra multiplexing.
      
      Introduce arch_evlist__add_default_attrs() to allow architecture
      specific default events. Add the Topdown metrics events in the X86
      specific arch_evlist__add_default_attrs(). Other architectures can add
      their own default events later separately.
      
      With the patch:
      
       $ perf stat sleep 1
      
       Performance counter stats for 'sleep 1':
      
                 0.82 msec task-clock:u              #    0.001 CPUs utilized
                    0      context-switches:u        #    0.000 K/sec
                    0      cpu-migrations:u          #    0.000 K/sec
                   61      page-faults:u             #    0.074 M/sec
              319,941      cycles:u                  #    0.388 GHz
              242,802      instructions:u            #    0.76  insn per cycle
               54,380      branches:u                #   66.028 M/sec
                4,043      branch-misses:u           #    7.43% of all branches
            1,585,555      slots:u                   # 1925.189 M/sec
              238,941      topdown-retiring:u        #     15.0% retiring
              410,378      topdown-bad-spec:u        #     25.8% bad speculation
              634,222      topdown-fe-bound:u        #     39.9% frontend bound
              304,675      topdown-be-bound:u        #     19.2% backend bound
      
             1.001791625 seconds time elapsed
      
             0.000000000 seconds user
             0.001572000 seconds sys
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lore.kernel.org/lkml/20210121133752.118327-1-kan.liang@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      42641d6f
    • John Garry's avatar
      perf test: Add parse-metric memory bandwidth testcase · 7efce5c2
      John Garry authored
      Event duration_time in a metric expression requires special handling.
      
      Improve test coverage by including a metric whose expression includes
      duration_time. The actual metric is a copied from the L1D_Cache_Fill_BW
      metric on my broadwell machine.
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linuxarm@openeuler.org
      Link: http://lore.kernel.org/lkml/1611578842-5749-1-git-send-email-john.garry@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      7efce5c2
  3. 02 Feb, 2021 19 commits