1. 17 1月, 2018 14 次提交
    • J
      perf script: Remove the time slices number limitation · cc2ef584
      Jin Yao 提交于
      Previously it was only allowed to use at most 10 time slices in 'perf
      script --time'.
      
      This patch removes this limitation.
      For example, following command line is OK (12 time slices)
      
      perf script --time 1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-9-git-send-email-yao.jin@linux.intel.com
      [ No need to check for NULL to call free, use zfree ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc2ef584
    • J
      perf report: Remove the time slices number limitation · 0a3cc3ae
      Jin Yao 提交于
      Previously it was only allowed to use at most 10 time slices in 'perf
      report --time'.
      
      This patch removes this limitation.
      For example, following command line is OK (12 time slices)
      
      perf report --stdio --time 1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-8-git-send-email-yao.jin@linux.intel.com
      [ No need to check for NULL to call free, use zfree ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a3cc3ae
    • J
      perf util: Allocate time slices buffer according to number of comma · 5a031f88
      Jin Yao 提交于
      Previously we use a magic number 10 to limit the number of time slices.
      It's not very good.
      
      This patch creates a new function perf_time__range_alloc() to allocate
      time slices buffer. The number of buffer entries is determined by the
      number of comma in string but at least it will allocate one entry even
      if no comma is found.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-7-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5a031f88
    • J
      perf report: Add an indication of what time slices are used · 7425664b
      Jin Yao 提交于
      Add a time slices indication to the perf report header.
      
      For example,
      
        # perf report --stdio --time 10%
      
        # Total Lost Samples: 0
        #
        # Samples: 9K of event 'cycles:ppp' (time slices: 10%)
        # Event count (approx.): 8951288803
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Suggested--by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-6-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7425664b
    • J
      perf util: Support no index time percent slice · 3002812e
      Jin Yao 提交于
      Previously, the time percent slice needs an index to specify which one
      the user wants.
      
      It may be easier to use if the index can be omitted.  So with this
      patch, for example,
      
      perf report --stdio --time 10%/1 should be equivalent to
      perf report --stdio --time 10%
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-5-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3002812e
    • J
      perf util: Improve error checking for time percent input · 6e761cbc
      Jin Yao 提交于
      The command line like 'perf report --stdio --time 1abc%/1' could be
      accepted by perf. It looks not very good.
      
      This patch uses strtod() to replace original atof() and check the entire
      string. Now for the same command line, it would return error message
      "Invalid time string".
      
      root@skl:/tmp# perf report --stdio --time 1abc%/1
      Invalid time string
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-4-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6e761cbc
    • J
      perf script: Improve error msg when no first/last sample time found · 1e2778e9
      Jin Yao 提交于
      The following message will be returned to user when executing 'perf
      script --time' if perf data file doesn't contain the first/last sample
      time.
      
      "HINT: no first/last sample time found in perf data.
       Please use latest perf binary to execute 'perf record'
       (if '--buildid-all' is enabled, needs to set '--timestamp-boundary')."
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-3-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1e2778e9
    • J
      perf report: Improve error msg when no first/last sample time found · eb0b419e
      Jin Yao 提交于
      The following message will be returned to user when executing
      'perf report --time' if perf data file doesn't contain the
      first/last sample time.
      
      "HINT: no first/last sample time found in perf data.
       Please use latest perf binary to execute 'perf record'
       (if '--buildid-all' is enabled, needs to set '--timestamp-boundary')."
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1515596433-24653-2-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      eb0b419e
    • A
      perf callchains: Ask for PERF_RECORD_MMAP for data mmaps for DWARF unwinding · 0d3dcc0e
      Arnaldo Carvalho de Melo 提交于
      When we use a global DWARF setting as in:
      
      	perf record --call-graph dwarf
      
      According to 5c0cf224 ("perf record: Store data mmaps for dwarf unwind") we need
      to set up some extra perf_event_attr bits.
      
      But when we instead do a per event dwarf setting:
      
      	perf record -e cycles/call-graph=dwarf/
      
      This was not being done, make them equivalent.
      
      This didn't produce any output changes in my tests while fixing up loose
      ends in the per-event settings, I found it just by comparing the
      perf_event_attr fields trying to find an explanation for those problems.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Noel Grandin <noelgrandin@gmail.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-6476r53h2o38skbs9qa4ust4@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0d3dcc0e
    • A
      perf trace: Allow overriding global --max-stack per event · bd3dda9a
      Arnaldo Carvalho de Melo 提交于
      The per-event max-stack setting wasn't overriding the global --max-stack
      setting:
      
        # perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf,max-stack=2/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
             0.000 probe_libc:inet_pton:(7feb7a998350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa39b6108f3f] (/usr/bin/ping)
        #
      
      Fix it:
      
        # perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf,max-stack=2/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.073 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.073/0.073/0.073/0.000 ms
             0.000 probe_libc:inet_pton:(7f1083221350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-ic3g837xg8ob3kcpkspxwz0g@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bd3dda9a
    • A
      perf trace: Setup DWARF callchains for non-syscall events when --max-stack is used · 75d50117
      Arnaldo Carvalho de Melo 提交于
      If we use:
      
      	perf trace --max-stack=4
      
      then the syscall events will use DWARF callchains, when available
      (libunwind enabled in the build) and the printing will stop at 4 levels.
      
      When we introduced support for tracepoint events this ended up not
      applying for them, fix it.
      
      Before:
      
        # perf trace --call-graph=dwarf --no-syscalls -e probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.058 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms
             0.000 probe_libc:inet_pton:(7fc6c2a16350))
        #
      
      After:
      
        # perf trace --call-graph=dwarf --no-syscalls -e probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.087 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.087/0.087/0.087/0.000 ms
             0.000 probe_libc:inet_pton:(7fbf9a041350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa947cb67f3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa947cb68379] (/usr/bin/ping)
        #
      Reported-by: NThomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.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-afsu9eegd43ppihiuafhh9qv@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      75d50117
    • A
      perf unwind: Do not look just at the global callchain_param.record_mode · eabad8c6
      Arnaldo Carvalho de Melo 提交于
      When setting up DWARF callchains on specific events, without using
      'record' or 'trace' --call-graph, but instead doing it like:
      
      	perf trace -e cycles/call-graph=dwarf/
      
      The unwind__prepare_access() call in thread__insert_map() when we
      process PERF_RECORD_MMAP(2) metadata events were not being performed,
      precluding us from using per-event DWARF callchains, handling them just
      when we asked for all events to be DWARF, using "--call-graph dwarf".
      
      We do it in the PERF_RECORD_MMAP because we have to look at one of the
      executable maps to figure out the executable type (64-bit, 32-bit) of
      the DSO laid out in that mmap. Also to look at the architecture where
      the perf.data file was recorded.
      
      All this probably should be deferred to when we process a sample for
      some thread that has callchains, so that we do this processing only for
      the threads with samples, not for all of them.
      
      For now, fix using DWARF on specific events.
      
      Before:
      
        # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.048 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms
           0.000 probe_libc:inet_pton:(7fe9597bb350))
        Problem processing probe_libc:inet_pton callchain, skipping...
        #
      
      After:
      
        # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.060 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.060/0.060/0.060/0.000 ms
             0.000 probe_libc:inet_pton:(7fd4aa930350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa804e51af3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa804e51b379] (/usr/bin/ping)
        #
        # perf trace --call-graph=dwarf --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.057 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
             0.000 probe_libc:inet_pton:(7f9363b9e350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffa9e8a14e0f3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffa9e8a14e1379] (/usr/bin/ping)
        #
        # perf trace --call-graph=fp --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.077 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
             0.000 probe_libc:inet_pton:(7f4947e1c350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa716d88ef3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa716d88f379] (/usr/bin/ping)
        #
        # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=fp/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.078 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.078/0.078/0.078/0.000 ms
             0.000 probe_libc:inet_pton:(7fa157696350))
                                               __GI___inet_pton (/usr/lib64/libc-2.26.so)
                                               getaddrinfo (/usr/lib64/libc-2.26.so)
                                               [0xffffa9ba39c74f40] (/usr/bin/ping)
        #
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/r/20180116182650.GE16107@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      eabad8c6
    • A
      perf callchain: Fix attr.sample_max_stack setting · 249d98e5
      Arnaldo Carvalho de Melo 提交于
      When setting the "dwarf" unwinder for a specific event and not
      specifying the max-stack, the attr.sample_max_stack ended up using an
      uninitialized callchain_param.max_stack, fix it by using designated
      initializers for that callchain_param variable, zeroing all non
      explicitely initialized struct members.
      
      Here is what happened:
      
        # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        callchain: type DWARF
        callchain: stack dump size 8192
        perf_event_attr:
          type                             2
          size                             112
          config                           0x730
          { sample_period, sample_freq }   1
          sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
          exclude_callchain_user           1
          { wakeup_events, wakeup_watermark } 1
          sample_regs_user                 0xff0fff
          sample_stack_user                8192
          sample_max_stack                 50656
        sys_perf_event_open failed, error -75
        Value too large for defined data type
        # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        callchain: type DWARF
        callchain: stack dump size 8192
        perf_event_attr:
          type                             2
          size                             112
          config                           0x730
          sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
          exclude_callchain_user           1
          sample_regs_user                 0xff0fff
          sample_stack_user                8192
          sample_max_stack                 30448
        sys_perf_event_open failed, error -75
        Value too large for defined data type
        #
      
      Now the attr.sample_max_stack is set to zero and the above works as
      expected:
      
        # perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
             0.000 probe_libc:inet_pton:(7feb7a998350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa39b6108f3f] (/usr/bin/ping)
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-is9tramondqa9jlxxsgcm9iz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      249d98e5
    • K
      perf tools: Add ARM Statistical Profiling Extensions (SPE) support · ffd3d18c
      Kim Phillips 提交于
      'perf record' and 'perf report --dump-raw-trace' supported in this
      release.
      
      Example usage:
      
       # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero of=/dev/null count=10000
       # perf report --dump-raw-trace
      
      Note that the perf.data file is portable, so the report can be run on
      another architecture host if necessary.
      
      Output will contain raw SPE data and its textual representation, such
      as:
      
      0x5c8 [0x30]: PERF_RECORD_AUXTRACE size: 0x200000  offset: 0  ref: 0x1891ad0e  idx: 1  tid: 2227  cpu: 1
      .
      . ... ARM SPE data: size 2097152 bytes
      .  00000000:  49 00                                           LD
      .  00000002:  b2 c0 3b 29 0f 00 00 ff ff                      VA 0xffff00000f293bc0
      .  0000000b:  b3 c0 eb 24 fb 00 00 00 80                      PA 0xfb24ebc0 ns=1
      .  00000014:  9a 00 00                                        LAT 0 XLAT
      .  00000017:  42 16                                           EV RETIRED L1D-ACCESS TLB-ACCESS
      .  00000019:  b0 00 c4 15 08 00 00 ff ff                      PC 0xff00000815c400 el3 ns=1
      .  00000022:  98 00 00                                        LAT 0 TOT
      .  00000025:  71 36 6c 21 2c 09 00 00 00                      TS 39395093558
      .  0000002e:  49 00                                           LD
      .  00000030:  b2 80 3c 29 0f 00 00 ff ff                      VA 0xffff00000f293c80
      .  00000039:  b3 80 ec 24 fb 00 00 00 80                      PA 0xfb24ec80 ns=1
      .  00000042:  9a 00 00                                        LAT 0 XLAT
      .  00000045:  42 16                                           EV RETIRED L1D-ACCESS TLB-ACCESS
      .  00000047:  b0 f4 11 16 08 00 00 ff ff                      PC 0xff0000081611f4 el3 ns=1
      .  00000050:  98 00 00                                        LAT 0 TOT
      .  00000053:  71 36 6c 21 2c 09 00 00 00                      TS 39395093558
      .  0000005c:  48 00                                           INSN-OTHER
      .  0000005e:  42 02                                           EV RETIRED
      .  00000060:  b0 2c ef 7f 08 00 00 ff ff                      PC 0xff0000087fef2c el3 ns=1
      .  00000069:  98 00 00                                        LAT 0 TOT
      .  0000006c:  71 d1 6f 21 2c 09 00 00 00                      TS 39395094481
      ...
      
      Other release notes:
      
      - applies to acme's perf/{core,urgent} branches, likely elsewhere
      
      - Report is self-contained within the tool.
        Record requires enabling the kernel SPE driver by
        setting CONFIG_ARM_SPE_PMU.
      
      - The intel-bts implementation was used as a starting point; its
        min/default/max buffer sizes and power of 2 pages granularity need to be
        revisited for ARM SPE
      
      - Recording across multiple SPE clusters/domains not supported
      
      - Snapshot support (record -S), and conversion to native perf events
        (e.g., via 'perf inject --itrace'), are also not supported
      
      - Technically both cs-etm and spe can be used simultaneously, however
        disabled for simplicity in this release
      Signed-off-by: NKim Phillips <kim.phillips@arm.com>
      Reviewed-by: NDongjiu Geng <gengdongjiu@huawei.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: http://lkml.kernel.org/r/20180114132850.0b127434b704a26bad13268f@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ffd3d18c
  2. 13 1月, 2018 4 次提交
    • A
      perf trace: Fix setting of --call-graph/--max-stack for non-syscall events · 08e26396
      Arnaldo Carvalho de Melo 提交于
      The raw_syscalls:sys_{enter,exit} were first supported in 'perf trace',
      together with minor and major page faults, then we supported
      --call-graph, then --max-stack, but when the other tracepoints got
      supported, and bpf, etc, I forgot to make those global call-graph
      settings apply to them.
      
      Fix it by realizing that the global --max-stack and --call-graph
      settings are done via:
      
              OPT_CALLBACK(0, "call-graph", &trace.opts,
                           "record_mode[,record_size]", record_callchain_help,
                           &record_parse_callchain_opt),
      
      And then, when we go to parse the events in -e via:
      
              OPT_CALLBACK('e', "event", &trace, "event",
                           "event/syscall selector. use 'perf list' to list available events",
                           trace__parse_events_option),
      
      And trace__parse_sevents_option() calls:
      
                      struct option o = OPT_CALLBACK('e', "event", &trace->evlist, "event",
                                                     "event selector. use 'perf list' to list available events",
                                                     parse_events_option);
                      err = parse_events_option(&o, lists[0], 0);
      
      parse_events_option() will override the global --call-graph and
      --max-stack if the "call-graph" and/or "max-stack" terms are in the
      event definition, such as in the probe_libc:inet_pton event in one of the
      examples below (-e probe_libc:inet_pton/max-stack=2).
      
      Before:
      
        # perf trace --mmap 1024 --call-graph dwarf -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
             1.525 (         ): probe_libc:inet_pton:(7f77f3ac9350))
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.071 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.071/0.071/0.071/0.000 ms
             1.677 ( 0.081 ms): ping/31296 sendto(fd: 3, buff: 0x55681b652720, len: 64, addr: 0x55681b650640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa97e4bc9cef] (/usr/bin/ping)
                                               [0xffffaa97e4bc656d] (/usr/bin/ping)
                                               [0xffffaa97e4bc7d0a] (/usr/bin/ping)
                                               [0xffffaa97e4bca447] (/usr/bin/ping)
                                               [0xffffaa97e4bc2f91] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa97e4bc3379] (/usr/bin/ping)
        #
      
      After:
      
        # perf trace --mmap 1024 --call-graph dwarf -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.089 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.089/0.089/0.089/0.000 ms
             1.955 (         ): probe_libc:inet_pton:(7f383a311350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa5d91444f3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d91445379] (/usr/bin/ping)
             2.140 ( 0.101 ms): ping/32047 sendto(fd: 3, buff: 0x55a26edd0720, len: 64, addr: 0x55a26edce640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d9144bcef] (/usr/bin/ping)
                                               [0xffffaa5d9144856d] (/usr/bin/ping)
                                               [0xffffaa5d91449d0a] (/usr/bin/ping)
                                               [0xffffaa5d9144c447] (/usr/bin/ping)
                                               [0xffffaa5d91444f91] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d91445379] (/usr/bin/ping)
        #
      
      Same thing for --max-stack, the global one:
      
        # perf trace --max-stack 3 -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.097 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.097/0.097/0.097/0.000 ms
             1.577 (         ): probe_libc:inet_pton:(7f32f3957350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
             1.738 ( 0.108 ms): ping/32103 sendto(fd: 3, buff: 0x55c3132d7720, len: 64, addr: 0x55c3132d5640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa3cecf44cef] (/usr/bin/ping)
                                               [0xffffaa3cecf4156d] (/usr/bin/ping)
        #
      
      And then setting up a global setting (dwarf, max-stack=4), that will
      affect the raw_syscall:sys_enter for the 'sendto' syscall and that will
      be overriden in the probe_libc:inet_pton call to just one entry.
      
        # perf trace --max-stack=4 --call-graph dwarf -e sendto -e probe_libc:inet_pton/max-stack=1/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.090 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.090/0.090/0.090/0.000 ms
             2.140 (         ): probe_libc:inet_pton:(7f9fe9337350))
                                               __GI___inet_pton (/usr/lib64/libc-2.26.so)
             2.283 ( 0.103 ms): ping/31804 sendto(fd: 3, buff: 0x55c7f3e19720, len: 64, addr: 0x55c7f3e17640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa380c402cef] (/usr/bin/ping)
                                               [0xffffaa380c3ff56d] (/usr/bin/ping)
                                               [0xffffaa380c400d0a] (/usr/bin/ping)
        #
      
      Install iputils-debuginfo to get those /usr/bin/ping addresses resolved,
      those routines are not on its .dymsym nor .symtab :-)
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-qgl2gse8elhh9zztw4ajopg3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      08e26396
    • A
      perf evsel: Check if callchain is enabled before setting it up · 1688c2fd
      Arnaldo Carvalho de Melo 提交于
      The construct:
      
      	if (callchain_param)
      		perf_evsel__config_callchain(evsel, opts, &callchain_param);
      
      happens in several places, so make perf_evsel__config_callchain() work
      just like free(NULL), do nothing if param->enabled is not set.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-ykk0qzxnxwx3o611ctjnmxav@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1688c2fd
    • J
      perf tools: Fix copyfile_offset update of output offset · fa1195cc
      Jiri Olsa 提交于
      We need to increase output offset in each iteration, not decrease it as
      we currently do.
      
      I guess we were lucky to finish in most cases in first iteration, so the
      bug never showed. However it shows a lot when working with big (~4GB)
      size data.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: 9c9f5a2f ("perf tools: Introduce copyfile_offset() function")
      Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fa1195cc
    • A
      perf trace: No need to set PERF_SAMPLE_IDENTIFIER explicitely · 236d812c
      Arnaldo Carvalho de Melo 提交于
      Since 75562573 ("perf tools: Add support for
      PERF_SAMPLE_IDENTIFIER") we don't need explicitely set
      PERF_SAMPLE_IDENTIFIER, as perf_evlist__config() will do this for us,
      i.e. when there are more than one evsel in an evlist, it will check if
      some evsel has a sample_type different than the one on the first evsel
      in the list, setting PERF_SAMPLE_IDENTIFIER in that case.
      
      So, to simplify 'perf trace' codebase, ditch that check.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-12xq6orhwttee2tdtu96ucrp@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      236d812c
  3. 12 1月, 2018 2 次提交
  4. 11 1月, 2018 1 次提交
  5. 10 1月, 2018 6 次提交
    • A
      perf report: Introduce --mmaps · 6439d7d1
      Arnaldo Carvalho de Melo 提交于
      Similar to --tasks, producing the same output plus /proc/<PID>/maps
      similar lines for each mmap record present in a perf.data file.
      
      Please note that not all mmaps are stored, for instance, some of the
      non-executable mmaps are only stored when 'perf record --data' is used,
      when the user wants to resolve data accesses in addition to asking for
      executable mmaps to get the DSO with symtabs.
      
      E.g.:
      
        # perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (7 samples) ]
        [root@jouet ~]# perf report --mmaps
        #      pid      tid     ppid  comm
                 0        0       -1 |swapper
              4137     4137       -1 |sleep
                                        5628a35a1000-5628a37aa000 r-xp 00000000 3147148 /usr/bin/sleep
                                        7fb65ad51000-7fb65b134000 r-xp 00000000 3149795 /usr/lib64/libc-2.26.so
                                        7fb65b134000-7fb65b35e000 r-xp 00000000 3149715 /usr/lib64/ld-2.26.so
                                        7ffd94b9f000-7ffd94ba1000 r-xp 00000000 0 [vdso]
        #
        # perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.019 MB perf.data (8 samples) ]
        # perf report --mmaps
        #      pid      tid     ppid  comm
                 0        0       -1 |swapper
              4161     4161       -1 |sleep
                                        55afae69a000-55afae8a3000 r-xp 00000000 3147148 /usr/bin/sleep
                                        7f569f00d000-7f569f3f0000 r-xp 00000000 3149795 /usr/lib64/libc-2.26.so
                                        7f569f3f0000-7f569f61a000 r-xp 00000000 3149715 /usr/lib64/ld-2.26.so
                                        7fff6fffe000-7fff70000000 r-xp 00000000 0 [vdso]
        #
        # perf record time sleep 1
        0.00user 0.00system 0:01.00elapsed 0%CPU (0avgtext+0avgdata 2156maxresident)k
        0inputs+0outputs (0major+73minor)pagefaults 0swaps
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.019 MB perf.data (14 samples) ]
        # perf report --mmaps
        #      pid      tid     ppid  comm
                 0        0       -1 |swapper
              4281     4281       -1 |time
                                        560560dca000-560560fcf000 r-xp 00000000 3190458 /usr/bin/time
                                        7fc175196000-7fc175579000 r-xp 00000000 3149795 /usr/lib64/libc-2.26.so
                                        7fc175579000-7fc1757a3000 r-xp 00000000 3149715 /usr/lib64/ld-2.26.so
                                        7ffc924f6000-7ffc924f8000 r-xp 00000000 0 [vdso]
              4282     4282     4281 | sleep
                                         560560dca000-560560fcf000 r-xp 00000000 3190458 /usr/bin/time
                                         564b4de3c000-564b4e045000 r-xp 00000000 3147148 /usr/bin/sleep
                                         7f6a5a716000-7f6a5aaf9000 r-xp 00000000 3149795 /usr/lib64/libc-2.26.so
                                         7f6a5aaf9000-7f6a5ad23000 r-xp 00000000 3149715 /usr/lib64/ld-2.26.so
                                         7fc175196000-7fc175579000 r-xp 00000000 3149795 /usr/lib64/libc-2.26.so
                                         7fc175579000-7fc1757a3000 r-xp 00000000 3149715 /usr/lib64/ld-2.26.so
                                         7ffc924f6000-7ffc924f8000 r-xp 00000000 0 [vdso]
                                         7ffcec7e6000-7ffcec7e8000 r-xp 00000000 0 [vdso]
        #
      
      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-zulwdlg5rfowogr1qznorvvc@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6439d7d1
    • J
      perf report: Add --tasks option to display monitored tasks · 930f8b34
      Jiri Olsa 提交于
      Add --tasks option to display monitored tasks stored in perf.data.
      Displaying pid/tid/ppid plus the command string aligned to distinguish
      parent and child tasks.
      
        $ perf record -a
        ...
        $ perf report --tasks
        #     pid     tid    ppid  comm
                0       0      -1 |swapper
                2       2       0 | kthreadd
            14080   14080       2 |  kworker/u17:1
                4       4       2 |  kworker/0:0H
                6       6       2 |  mm_percpu_wq
        ...
                1       1       0 | systemd
            23242   23242       1 |  firefox
            23242   23298   23242 |   Cache2 I/O
            23242   23304   23242 |   GMPThread
        ...
             1195    1195       1 |  login
             1611    1611    1195 |   bash
             1639    1639    1611 |    startx
             1663    1663    1639 |     xinit
             1673    1673    1663 |      xmonad-x86_64-l
            23939   23939    1673 |       xterm
            23941   23941   23939 |        bash
            23963   23963   23941 |         mutt
            24954   24954   23963 |          offlineimap
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-13-jolsa@kernel.org
      [ Make it --tasks, plural, --task works as well, as its unambiguous ]
      [ Use machine__find_thread(), not findnew(), as pointed out by Namhyung ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      930f8b34
    • A
      perf trace: Beautify 'gettid' syscall result · 2d1073de
      Arnaldo Carvalho de Melo 提交于
      Before:
      
        # trace -a -e gettid sleep 0.01
      <SNIP>
           4.863 ( 0.005 ms): Chrome_ChildIO/26241 gettid() = 26241
           4.931 ( 0.004 ms): Chrome_IOThrea/26154 gettid() = 26154
           4.942 ( 0.001 ms): Chrome_IOThrea/26154 gettid() = 26154
           4.946 ( 0.001 ms): Chrome_IOThrea/26154 gettid() = 26154
           4.970 ( 0.002 ms): Chrome_IOThrea/26154 gettid() = 26154
        #
      
      After:
      
        # trace -a -e gettid sleep 0.01
           0.000 ( 0.009 ms): Chrome_IOThrea/26154 gettid() = 26154 (Chrome_IOThread)
      <SNIP>
           3.416 ( 0.002 ms): Chrome_ChildIO/26241 gettid() = 26241 (Chrome_ChildIOT)
           3.424 ( 0.001 ms): Chrome_ChildIO/26241 gettid() = 26241 (Chrome_ChildIOT)
           3.343 ( 0.002 ms): chrome/26116 gettid() = 26116 (chrome)
           3.386 ( 0.002 ms): Chrome_IOThrea/26154 gettid() = 26154 (Chrome_IOThread)
           4.003 ( 0.003 ms): Chrome_ChildIO/26241 gettid() = 26241 (Chrome_ChildIOT)
           4.031 ( 0.002 ms): Chrome_IOThrea/26154 gettid() = 26154 (Chrome_IOThread)
        #
      
      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-kyg4gz2yy0vkrrh2vtq29u71@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2d1073de
    • J
      perf report: Add --stats option to display quick data statistics · a4a4d0a7
      Jiri Olsa 提交于
      Add --stats option to display quick data statistics of event numbers,
      without any further processing, like the one at the end of the perf
      report -D command.
      
        $ perf report --stat
      
        Aggregated stats:
                   TOTAL events:       4566
                    MMAP events:        113
                    LOST events:         19
                    COMM events:          3
                    FORK events:        400
                  SAMPLE events:       3315
                   MMAP2 events:         32
          FINISHED_ROUND events:        681
              THREAD_MAP events:          1
                 CPU_MAP events:          1
               TIME_CONV events:          1
      
      I found this useful when hunting lost events for another change.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-12-jolsa@kernel.org
      [ Rename it to --stats, plural ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a4a4d0a7
    • J
      perf tools: Make the tool's warning messages optional · 075ca1eb
      Jiri Olsa 提交于
      I want to display the pure events status coming in the next patch and
      the tool's warnings are superfluous in the output. Making it optional,
      enabled by default.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-11-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      075ca1eb
    • J
      perf script: Add support to display lost events · 3d7c27b6
      Jiri Olsa 提交于
      Adding option to display lost events:
      
        $ perf script --show-lost-events ...
         mplayer 13810 [002] 468011.402396:        100 cycles:ppp:  ff..
         mplayer 13810 [002] 468011.402396: PERF_RECORD_LOST lost 3880
         mplayer 13810 [002] 468011.402397:        100 cycles:ppp:  ff..
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-10-jolsa@kernel.org
      [ Use PRIu64 when printing u64 values, fixing the build in some arches ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3d7c27b6
  6. 08 1月, 2018 13 次提交
    • J
      perf script: Add support to display sample misc field · 28a0b398
      Jiri Olsa 提交于
      Adding support to display sample misc field in form
      of letter for each bit:
      
        # perf script -F +misc ...
         sched-messaging  1414 K     28690.636582:       4590 cycles ...
         sched-messaging  1407 U     28690.636600:     325620 cycles ...
         sched-messaging  1414 K     28690.636608:      19473 cycles ...
        misc field  __________/
      
      The misc bits are assigned to following letters:
      
        PERF_RECORD_MISC_KERNEL        K
        PERF_RECORD_MISC_USER          U
        PERF_RECORD_MISC_HYPERVISOR    H
        PERF_RECORD_MISC_GUEST_KERNEL  G
        PERF_RECORD_MISC_GUEST_USER    g
        PERF_RECORD_MISC_MMAP_DATA*    M
        PERF_RECORD_MISC_COMM_EXEC     E
        PERF_RECORD_MISC_SWITCH_OUT    S
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-9-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      28a0b398
    • J
      perf tools: Display perf_event_attr::namespaces debug info · db9fc765
      Jiri Olsa 提交于
      Display namespaces bit in -vv debug display:
      
        $ perf record -vv --namespaces ...
        ...
        perf_event_attr:
          size                             112
          ...
          namespaces                       1
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-3-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      db9fc765
    • J
      perf tools: Enable LIBBABELTRACE by default · 24787afb
      Jiri Olsa 提交于
      There's no reason anymore to treat babel trace in a special way, because
      a) we no longer display its state b) the needed babeltrace library is
      now out and well adopted among distros.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180107160356.28203-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      24787afb
    • J
      perf script: Support time percent and multiple time ranges · 2ab046cd
      Jin Yao 提交于
      perf script has a --time option to limit the time range of output.  It
      only supports absolute time.
      
      Now this option is extended to support multiple time ranges and support
      the percent of time.
      
      For example:
      
      1. Select the first and second 10% time slices:
      
         perf script --time 10%/1,10%/2
      
      2. Select from 0% to 10% and 30% to 40% slices:
      
         perf script --time 0%-10%,30%-40%
      
      Changelog:
      
      v6: Fix the merge issue with latest perf/core branch.
          No functional changes.
      
      v5: Add checking of first/last sample time to detect if it's recorded
          in perf.data. If it's not recorded, returns error message to user.
      
      v4: Remove perf_time__skip_sample, only uses perf_time__ranges_skip_sample
      
      v3: Since the definitions of first_sample_time/last_sample_time
          are moved from perf_session to perf_evlist so change the
          related code.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-7-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2ab046cd
    • J
      perf report: Support time percent and multiple time ranges · 5b969bc7
      Jin Yao 提交于
      perf report has a --time option to limit the time range of output.  It
      only supports absolute time.
      
      Now this option is extended to support multiple time ranges and support
      the percent of time.
      
      For example:
      
      1. Select the first and second 10% time slices:
      
      perf report --time 10%/1,10%/2
      
      2. Select from 0% to 10% and 30% to 40% slices:
      
      perf report --time 0%-10%,30%-40%
      
      Changelog:
      
      v6: Fix the merge issue with latest perf/core branch.
          No functional changes.
      
      v5: Add checking of first/last sample time to detect if it's recorded
          in perf.data. If it's not recorded, returns error message to user.
      
      v4: Remove perf_time__skip_sample, only uses perf_time__ranges_skip_sample
      
      v3: Since the definitions of first_sample_time/last_sample_time
          are moved from perf_session to perf_evlist so change the
          related code.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-6-git-send-email-yao.jin@linux.intel.com
      [ Add missing colons at end of examples in the man page ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5b969bc7
    • J
      perf tools: Create function to perform multiple time range checking · 9a9b8b4b
      Jin Yao 提交于
      Previous patch supports the multiple time range.
      
      For example, select the first and second 10% time slices.
      perf report --time 10%/1,10%/2
      
      We need a function to check if a timestamp is in the ranges of
      [0, 10%) and [10%, 20%].
      
      Note that it includes the last element in [10%, 20%] but it doesn't
      include the last element in [0, 10%). It's to avoid the overlap.
      
      This patch implments a new function perf_time__ranges_skip_sample
      for this checking.
      
      Change log:
      
      v4: Let perf_time__ranges_skip_sample be compatible with
          perf_time__skip_sample when only one time range.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-5-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9a9b8b4b
    • J
      perf tools: Create function to parse time percent · 13a70f35
      Jin Yao 提交于
      Current perf report/script/... have a --time option to limit the time
      range of output. But right now it only supports absolute time, add
      support for time percentage.
      
      For example:
      
      1. Select the second 10% time slice
         perf report --time 10%/2
      
      2. Select from 0% to 10% time slice
         perf report --time 0%-10%
      
      It also support the multiple time ranges.
      
      3. Select the first and second 10% time slices
         perf report --time 10%/1,10%/2
      
      4. Select from 0% to 10% and 30% to 40% slices
         perf report --time 0%-10%,30%-40%
      
      Changelog:
      
      v4: An issue is found. Following passes.
          perf script --time 10%/10x12321xsdfdasfdsafdsafdsa
      
          Now it uses strtol to replace atoi.
      
      Committer notes:
      
      This just puts in place the infrastructure, so the examples in this cset
      comment will only work later, after more patches in this series are
      applied.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-4-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      13a70f35
    • J
      perf record: Record the first and last sample time in the header · 68588baf
      Jin Yao 提交于
      In the default 'perf record' configuration, all samples are processed,
      to create the HEADER_BUILD_ID table. So it's very easy to get the
      first/last samples and save the time to perf file header via the
      function write_sample_time().
      
      Later, at post processing time, perf report/script will fetch the time
      from perf file header.
      
      Committer testing:
      
        # perf record -a sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 2.099 MB perf.data (1101 samples) ]
        [root@jouet home]# perf report --header | grep "time of "
        # time of first sample : 22947.909226
        # time of last sample : 22948.910704
        #
        # perf report -D | grep PERF_RECORD_SAMPLE\(
        0 22947909226101 0x20bb68 [0x30]: PERF_RECORD_SAMPLE(IP, 0x4001): 0/0: 0xffffffffa21b1af3 period: 1 addr: 0
        0 22947909229928 0x20bb98 [0x30]: PERF_RECORD_SAMPLE(IP, 0x4001): 0/0: 0xffffffffa200d204 period: 1 addr: 0
        <SNIP>
        3 22948910397351 0x219360 [0x30]: PERF_RECORD_SAMPLE(IP, 0x4001): 28251/28251: 0xffffffffa22071d8 period: 169518 addr: 0
        0 22948910652380 0x20f120 [0x30]: PERF_RECORD_SAMPLE(IP, 0x4001): 0/0: 0xffffffffa2856816 period: 198807 addr: 0
        2 22948910704034 0x2172d0 [0x30]: PERF_RECORD_SAMPLE(IP, 0x4001): 0/0: 0xffffffffa2856816 period: 88111 addr: 0
        #
      
      Changelog:
      
      v7: Just update the patch description according to Arnaldo's suggestion.
      
      v6: Currently '--buildid-all' is not enabled at default. So the walking
          on all samples is the default operation. There is no big overhead
          to calculate the timestamp boundary in process_sample_event handler
          once we already go through all samples. So the timestamp boundary
          calculation is enabled by default when '--buildid-all' is not enabled.
      
          While if '--buildid-all' is enabled, we creates a new option
          "--timestamp-boundary" for user to decide if it enables the
          timestamp boundary calculation.
      
      v5: There is an issue that the sample walking can only work when
          '--buildid-all' is not enabled. So we need to let the walking
          be able to work even if '--buildid-all' is enabled and let the
          processing skips the dso hit marking for this case.
      
          At first, I want to provide a new option "--record-time-boundaries".
          While after consideration, I think a new option is not very
          necessary.
      
      v3: Remove the definitions of first_sample_time and last_sample_time
          from struct record and directly save them in perf_evlist.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-3-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      68588baf
    • J
      perf header: Add infrastructure to record first and last sample time · 6011518d
      Jin Yao 提交于
      perf report/script/... have a --time option to limit the time range of
      output. That's very useful to slice large traces, e.g. when processing
      the output of perf script for some analysis.
      
      But right now --time only supports absolute time. Also there is no fast
      way to get the start/end times of a given trace except for looking at
      it.  This makes it hard to e.g. only decode the first half of the trace,
      which is useful for parallelization of scripts
      
      Another problem is that perf records are variable size and there is no
      synchronization mechanism. So the only way to find the last sample
      reliably would be to walk all samples. But we want to avoid that in perf
      report/...  because it is already quite expensive. That is why storing
      the first sample time and last sample time in perf record is better.
      
      This patch creates a new header feature type HEADER_SAMPLE_TIME and
      related ops. Save the first sample time and the last sample time to the
      feature section in perf file header. That will be done when, for
      instance, processing build-ids, where we already have to process all
      samples to create the build-id table, take advantage of that to further
      amortize that processing by storing HEADER_SAMPLE_TIME to make 'perf
      report/script' faster when using --time.
      
      Committer testing:
      
      After this patch is applied the header is written with zeroes, we need
      the next patch, for "perf record" to actually write the timestamps:
      
        # perf report -D | grep PERF_RECORD_SAMPLE\(
        22501155244406 0x44f0 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 25016/25016: 0xffffffffa21be8c5 period: 1 addr: 0
        <SNIP>
        22501155793625 0x4a30 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 25016/25016: 0xffffffffa21ffd50 period: 2828043 addr: 0
        # perf report --header | grep "time of "
        # time of first sample : 0.000000
        # time of last sample : 0.000000
        #
      
      Changelog:
      
      v7: 1. Rebase to latest perf/core branch.
      
          2. Add following clarification in patch description according to
             Arnaldo's suggestion.
      
             "That will be done when, for instance, processing build-ids,
      	where we already have to process all samples to create the
      	build-id table, take advantage of that to further amortize
      	that processing by storing HEADER_SAMPLE_TIME to make
      	'perf report/script' faster when using --time."
      
      v4: Use perf script time style for timestamp printing. Also add with
          the printing of sample duration.
      
      v3: Remove the definitions of first_sample_time/last_sample_time from
          perf_session. Just define them in perf_evlist
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1512738826-2628-2-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6011518d
    • J
      perf report: Fix a no annotate browser displayed issue · 40c39e30
      Jin Yao 提交于
      When enabling '-b' option in perf record, for example,
      
        perf record -b ...
        perf report
      
      and then browsing the annotate browser from perf report (press 'A'), it
      would fail (annotate browser can't be displayed).
      
      It's because the '.add_entry_cb' op of struct report is overwritten by
      hist_iter__branch_callback() in builtin-report.c. But this function doesn't do
      something like mapping symbols and sources. So next, do_annotate() will return
      directly.
      
              notes = symbol__annotation(act->ms.sym);
              if (!notes->src)
                      return 0;
      
      This patch adds the lost code to hist_iter__branch_callback (refer to
      hist_iter__report_callback).
      
      v2:
      
      Fix a crash bug when perform 'perf report --stdio'.
      
      The reason is that we init the symbol annotation only in browser mode, it
      doesn't allocate/init resources for stdio mode.
      
      So now in hist_iter__branch_callback(), it will return directly if it's not in
      browser mode.
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1514284963-18587-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      40c39e30
    • J
      perf report: Fix a wrong offset issue when using /proc/kcore · 935f5a9d
      Jin Yao 提交于
      When a valid vmlinux is not found, 'perf report' falls back to look at
      /proc/kcore. In this case, it will report the impossible large offset.
      
      For example:
      
        # perf record -b -e cycles:k find /etc/ > /dev/null
        # perf report --stdio --branch-history
      
          22.77%  _vm_normal_page+18446603336221188162
                  |
                  ---page_remove_rmap +18446603336221188324
                     page_remove_rmap +18446603336221188487 (cycles:5)
                     unlock_page_memcg +18446603336221188096
                     page_remove_rmap +18446603336221188327 (cycles:1)
      
      The issue is the value which is passed to parameter 'addr' in
      __get_srcline() is the objdump address. It's not correct if we calculate
      the offset by using 'addr - sym->start'.
      
      This patch creates a new parameter 'ip' in __get_srcline(). It is not
      converted to objdump address.
      
      With this patch, the perf report output is:
      
          22.77%  _vm_normal_page+66
                  |
                  ---page_remove_rmap +228
                     page_remove_rmap +391 (cycles:5)
                     unlock_page_memcg +0
                     page_remove_rmap +231 (cycles:1)
                     page_remove_rmap +236
      
      Committer testing:
      
      Make sure you get any valid vmlinux out of the way, using '-v' on the
      'perf report' case and deleting it from places where perf searches them,
      like your kernel build dir and the build-id cache, in ~/.debug/.
      Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NJin Yao <yao.jin@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1514564812-17344-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      935f5a9d
    • W
      perf tools: Fix compile error with libunwind x86 · 44df1afd
      Wang Nan 提交于
      Fix a compile error:
      
       ...
         CC       util/libunwind/x86_32.o
       In file included from util/libunwind/x86_32.c:33:0:
       util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function 'libunwind__x86_reg_id':
       util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error: 'EINVAL' undeclared (first use in this function)
          return -EINVAL;
                  ^
       util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: note: each undeclared identifier is reported only once for each function it appears in
       mv: cannot stat 'util/libunwind/.x86_32.o.tmp': No such file or directory
       make[4]: *** [util/libunwind/x86_32.o] Error 1
       make[3]: *** [util] Error 2
       make[2]: *** [libperf-in.o] Error 2
       make[1]: *** [sub-make] Error 2
       make: *** [all] Error 2
      
      It happens when libunwind-x86 feature is detected.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20171206015040.114574-1-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      44df1afd
    • A
      perf test bpf: Hook on epoll_pwait() · e0337f4f
      Arnaldo Carvalho de Melo 提交于
      The 'perf test bpf' was hooking a eBPF program on the SyS_epoll_wait()
      kernel function, that was what the epoll_wait() glibc function ended up
      calling, but since at least glibc 2.26, the one that comes with, for
      instance, Fedora 27, glibc ends up calling SyS_epoll_pwait() when
      epoll_wait() is used, causing this 'perf test' entry to fail.
      
      So switch to using epoll_pwait() and hook the eBPF program to the
      SyS_epoll_pwait() kernel function to make it work on a wider range of
      glibc and kernel versions.
      Tested-by: NWang Nan <wangnan0@huawei.com>
      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>
      Link: https://lkml.kernel.org/n/tip-zynvquy63er8s5mrgsz65pto@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e0337f4f