1. 09 7月, 2019 26 次提交
  2. 08 7月, 2019 1 次提交
    • A
      tools build: Check if gettid() is available before providing helper · 05c78468
      Arnaldo Carvalho de Melo 提交于
      Laura reported that the perf build failed in fedora when we got a glibc
      that provides gettid(), which I reproduced using fedora rawhide with the
      glibc-devel-2.29.9000-26.fc31.x86_64 package.
      
      Add a feature check to avoid providing a gettid() helper in such
      systems.
      
      On a fedora rawhide system with this patch applied we now get:
      
        [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=1
        [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output
        [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin
                linux-vdso.so.1 (0x00007ffc6b1f6000)
                libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000)
        [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid
                         U gettid@@GLIBC_2.30
        [root@7a5f55352234 perf]#
      
      While on a fedora:29 system:
      
        [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=0
        [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output
        test-gettid.c: In function ‘main’:
        test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration]
          return gettid();
                 ^~~~~~
                 getgid
        cc1: all warnings being treated as errors
        [acme@quaco perf]$
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Florian Weimer <fweimer@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      05c78468
  3. 07 7月, 2019 8 次提交
    • J
      perf jvmti: Address gcc string overflow warning for strncpy() · dab0f4eb
      Jiri Olsa 提交于
      We are getting false positive gcc warning when we compile with gcc9 (9.1.1):
      
           CC       jvmti/libjvmti.o
         In file included from /usr/include/string.h:494,
                          from jvmti/libjvmti.c:5:
         In function ‘strncpy’,
             inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
         /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
           106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
               |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
         jvmti/libjvmti.c:165:26: note: length computed here
           165 |   size_t file_name_len = strlen(file_name);
               |                          ^~~~~~~~~~~~~~~~~
         cc1: all warnings being treated as errors
      
      As per Arnaldo's suggestion use strlcpy(), which does the same thing and keeps
      gcc silent.
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190531131321.GB1281@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dab0f4eb
    • A
      perf python: Remove -fstack-protector-strong if clang doesn't have it · c18ae632
      Arnaldo Carvalho de Melo 提交于
      Some distros put -fstack-protector-strong in the compiler flags to be
      used to build python extensions, but then, the clang version in that
      distro doesn't know about that, only gcc does.
      
      Check if that is the case and remove it from the set of options used to
      build the python binding with clang.
      
      Case at hand:
      
      oraclelinux:7
      
        $ head -2 /etc/os-release
        NAME="Oracle Linux Server"
        VERSION="7.6"
        $ grep stack-protector /usr/lib64/python2.7/_sysconfigdata.py | head -1 | cut -c-120
       'CFLAGS': '-fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --para
        $
        gcc version 4.8.5 20150623 (Red Hat 4.8.5-36.0.1) (GCC)
        clang version 3.4.2 (tags/RELEASE_34/dot2-final)
      
        clang: error: unknown argument: '-fstack-protector-strong'
        clang: error: unknown argument: '-fstack-protector-strong'
        error: command 'clang' failed with exit status 1
        cp: cannot stat '/tmp/build/perf/python_ext_build/lib/perf*.so': No such file or directory
        make[2]: *** [/tmp/build/perf/python/perf.so] Error 1
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lkml.kernel.org/n/tip-brmp2415zxpbhz45etkgjoma@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c18ae632
    • A
      perf annotate TUI browser: Do not use member from variable within its own initialization · d5b2179d
      Arnaldo Carvalho de Melo 提交于
      Some compilers will complain when using a member of a struct to
      initialize another member, in the same struct initialization.
      
      For instance:
      
        debian:8      Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
        oraclelinux:7 clang version 3.4.2 (tags/RELEASE_34/dot2-final)
      
      Produce:
      
        ui/browsers/annotate.c:104:12: error: variable 'ops' is uninitialized when used within its own initialization [-Werror,-Wuninitialized]
                                                    (!ops.current_entry ||
                                                      ^~~
        1 error generated.
      
      So use an extra variable, initialized just before that struct, to have
      the value used in the expressions used to init two of the struct
      members.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: c298304b ("perf annotate: Use a ops table for annotation_line__write()")
      Link: https://lkml.kernel.org/n/tip-f9nexro58q62l3o9hez8hr0i@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d5b2179d
    • S
      perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 · bff5a556
      Seeteena Thoufeek 提交于
      'probe libc's inet_pton & backtrace it with ping' testcase sometimes
      fails on powerpc because distro ping binary does not have symbol
      information and thus it prints "[unknown]" function name in the
      backtrace.
      
      Accept "[unknown]" as valid function name for powerpc as well.
      
       # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
      Before:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79695
        ping 79718 [077] 96483.787025: probe_libc:inet_pton: (7fff83a754c8)
        7fff83a754c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fff83a2b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fff83a2c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        1171830f4 [unknown] (/usr/bin/ping)
        FAIL: expected backtrace entry
        ".*\+0x[[:xdigit:]]+[[:space:]]\(.*/bin/ping.*\)$"
        got "1171830f4 [unknown] (/usr/bin/ping)"
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
      After:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79085
        ping 79108 [045] 96400.214177: probe_libc:inet_pton: (7fffbb9654c8)
        7fffbb9654c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fffbb91b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fffbb91c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        132e830f4 [unknown] (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
      Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Reviewed-by: NKim Phillips <kim.phillips@amd.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Fixes: 16329364 ("perf tests: Fix record+probe_libc_inet_pton.sh without ping's debuginfo")
      Link: http://lkml.kernel.org/r/1561630614-3216-1-git-send-email-s1seetee@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bff5a556
    • J
      perf evsel: Do not rely on errno values for precise_ip fallback · cd136189
      Jiri Olsa 提交于
      Konstantin reported problem with default perf record command, which
      fails on some AMD servers, because of the default maximum precise
      config.
      
      The current fallback mechanism counts on getting ENOTSUP errno for
      precise_ip fails, but that's not the case on some AMD servers.
      
      We can fix this by removing the errno check completely, because the
      precise_ip fallback is separated. We can just try  (if requested by
      evsel->precise_max) all possible precise_ip, and if one succeeds we win,
      if not, we continue with standard fallback.
      Reported-by: NKonstantin Kharlamov <Hi-Angel@yandex.ru>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Monnet <quentin.monnet@netronome.com>
      Cc: Kim Phillips <kim.phillips@amd.com>
      Link: http://lkml.kernel.org/r/20190703080949.10356-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cd136189
    • A
      perf thread: Allow references to thread objects after machine__exit() · 4c00af0e
      Arnaldo Carvalho de Melo 提交于
      Threads are created when we either synthesize PERF_RECORD_FORK events
      for pre-existing threads or when we receive PERF_RECORD_FORK events from
      the kernel as new threads get created.
      
      We then keep them in machine->threads[].entries rb trees till when we
      receive a PERF_RECORD_EXIT, i.e. that thread terminated.
      
      The thread object has a reference count that is grabbed when, for
      instance, we keep that thread referenced in struct hist_entry, in 'perf
      report' and 'perf top'.
      
      When we receive a PERF_RECORD_EXIT we remove the thread object from the
      rb tree and move it to the corresponding machine->threads[].dead list,
      then we do a thread__put(), dropping the reference we had for keeping it
      in the rb tree.
      
      In thread__put() we were assuming that when the reference count hit zero
      we should remove it from the dead list by simply doing a
      list_del_init(&thread->node).
      
      That works well when all the thread lifetime is during the machine that
      has the list heads lifetime, since we know that we can do the
      list_del_init() and it will update the 'dead' list_head.
      
      But in 'perf sched lat' we were doing:
      
          machine__new() (via perf_session__new)
      
          process events, grabbing refcounts to keep those thread objects
          in 'perf sched' local data structures.
      
          machine__exit() (via perf_session__delete) which would delete the
          'dead' list heads.
      
          And then doing the final thread__put() for the refcounts 'perf sched'
          rightfully obtained for keeping those thread object references.
      
          b00m, since thread__put() would do the list_del_init() touching
          a dead dead list head.
      
      Fix it by removing all the dead threads from machine->threads[].dead at
      machine__exit(), since whatever is there should have refcounts taken by
      things like 'perf sched lat', and make thread__put() check if the thread
      is in a linked list before removing it from that list.
      Reported-by: NWei Li <liwei391@huawei.com>
      Link: https://lkml.kernel.org/r/20190508143648.8153-1-liwei391@huawei.com
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Zhipeng Xie <xiezhipeng1@huawei.com>
      Link: https://lkml.kernel.org/r/20190704194355.GI10740@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4c00af0e
    • S
      perf header: Assign proper ff->ph in perf_event__synthesize_features() · c952b35f
      Song Liu 提交于
      bpf/btf write_* functions need ff->ph->env.
      
      With this missing, pipe-mode (perf record -o -)  would crash like:
      
      Program terminated with signal SIGSEGV, Segmentation fault.
      
      This patch assign proper ph value to ff.
      
      Committer testing:
      
        (gdb) run record -o -
        Starting program: /root/bin/perf record -o -
        PERFILE2
        <SNIP start of perf.data headers>
        Thread 1 "perf" received signal SIGSEGV, Segmentation fault.
        __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
        126		memcpy(ff->buf + ff->offset, buf, size);
        (gdb) bt
        #0  __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
        #1  do_write (ff=ff@entry=0x7fffffff8f80, buf=buf@entry=0x160, size=4) at util/header.c:137
        #2  0x00000000004eddba in write_bpf_prog_info (ff=0x7fffffff8f80, evlist=<optimized out>) at util/header.c:912
        #3  0x00000000004f69d7 in perf_event__synthesize_features (tool=tool@entry=0x97cc00 <record>, session=session@entry=0x7fffe9c6d010,
            evlist=0x7fffe9cae010, process=process@entry=0x4435d0 <process_synthesized_event>) at util/header.c:3695
        #4  0x0000000000443c79 in record__synthesize (tail=tail@entry=false, rec=0x97cc00 <record>) at builtin-record.c:1214
        #5  0x0000000000444ec9 in __cmd_record (rec=0x97cc00 <record>, argv=<optimized out>, argc=0) at builtin-record.c:1435
        #6  cmd_record (argc=0, argv=<optimized out>) at builtin-record.c:2450
        #7  0x00000000004ae3e9 in run_builtin (p=p@entry=0x98e058 <commands+216>, argc=argc@entry=3, argv=0x7fffffffd670) at perf.c:304
        #8  0x000000000042eded in handle_internal_command (argv=<optimized out>, argc=<optimized out>) at perf.c:356
        #9  run_argv (argcp=<optimized out>, argv=<optimized out>) at perf.c:400
        #10 main (argc=3, argv=<optimized out>) at perf.c:522
        (gdb)
      
      After the patch the SEGSEGV is gone.
      Reported-by: NDavid Carrillo Cisneros <davidca@fb.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: kernel-team@fb.com
      Cc: stable@vger.kernel.org # v5.1+
      Fixes: 606f972b ("perf bpf: Save bpf_prog_info information as headers to perf.data")
      Link: http://lkml.kernel.org/r/20190620010453.4118689-1-songliubraving@fb.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c952b35f
    • A
      tools arch kvm: Sync kvm headers with the kernel sources · c499d1f4
      Arnaldo Carvalho de Melo 提交于
      To pick up the changes from:
      
        41040cf7 ("arm64/sve: Fix missing SVE/FPSIMD endianness conversions")
        6ca00dfa ("KVM: x86: Modify struct kvm_nested_state to have explicit fields for data")
      
      None entail changes in tooling.
      
      This silences these tools/perf build warnings:
      
        Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h'
        diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h
        Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/kvm.h' differs from latest version at 'arch/arm64/include/uapi/asm/kvm.h'
        diff -u tools/arch/arm64/include/uapi/asm/kvm.h arch/arm64/include/uapi/asm/kvm.h
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Liran Alon <liran.alon@oracle.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: https://lkml.kernel.org/n/tip-1cdbq5ulr4d6cx3iv2ye5wdv@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c499d1f4
  4. 03 7月, 2019 5 次提交
    • A
      selftests/x86/fsgsbase: Fix some test case bugs · 697096b1
      Andy Lutomirski 提交于
      This refactors do_unexpected_base() to clean up some code.  It also
      fixes the following bugs in test_ptrace_write_gsbase():
      
       - Incorrect printf() format string caused crashes.
      
       - Hardcoded 0x7 for the gs selector was not reliably correct.
      
      It also documents the fact that the test is expected to fail on old
      kernels.
      
      Fixes: a87730cc ("selftests/x86/fsgsbase: Test ptracer-induced GSBASE write with FSGSBASE")
      Fixes: 1b6858d5 ("selftests/x86/fsgsbase: Test ptracer-induced GSBASE write")
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc:  "BaeChang Seok" <chang.seok.bae@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: "BaeChang Seok" <chang.seok.bae@intel.com>
      Link: https://lkml.kernel.org/r/bab29c84f2475e2c30ddb00f1b877fcd7f4f96a8.1562125333.git.luto@kernel.org
      
      697096b1
    • A
      perf script: Allow specifying the files to process guest samples · 15a108af
      Arnaldo Carvalho de Melo 提交于
      The 'perf kvm' command set up things so that we can record, report, top,
      etc, but not 'script', so make 'perf script' be able to process samples
      by allowing to pass guest kallsyms, vmlinux, modules, etc, and if at
      least one of those is provided, set perf_guest to true so that guest
      samples get properly resolved.
      
      Testing it:
      
        # perf kvm --guest --guestkallsyms /wb/rhel6.kallsyms --guestmodules /wb/rhel6.modules record -e cycles:Gk
      ^C[ perf record: Woken up 7 times to write data ]
        [ perf record: Captured and wrote 3.602 MB perf.data.guest (10492 samples) ]
      
        #
        # perf evlist -i perf.data.guest
      cycles:Gk
        # perf evlist -v -i perf.data.guest
      cycles:Gk: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD, read_format: ID, disabled: 1, inherit: 1, exclude_user: 1, exclude_hv: 1, mmap: 1, comm: 1, freq: 1, task: 1, sample_id_all: 1, exclude_host: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1
        #
        # perf kvm --guestkallsyms /wb/rhel6.kallsyms --guestmodules /wb/rhel6.modules report --stdio -s sym | head -30
        # To display the perf.data header info, please use --header/--header-only options.
        #
        #
        # Total Lost Samples: 0
        #
        # Samples: 10K of event 'cycles:Gk'
        # Event count (approx.): 2434201408
        #
        # Overhead  Symbol
        # ........  ..............................................
        #
            11.93%  [g] avtab_search_node
             3.95%  [g] sidtab_context_to_sid
             2.41%  [g] n_tty_write
             2.20%  [g] _spin_unlock_irqrestore
             1.37%  [g] _aesni_dec4
             1.33%  [g] kmem_cache_alloc
             1.07%  [g] native_write_cr0
             0.99%  [g] kfree
             0.95%  [g] _spin_lock
             0.91%  [g] __memset
             0.87%  [g] schedule
             0.83%  [g] _spin_lock_irqsave
             0.76%  [g] __kmalloc
             0.67%  [g] avc_has_perm_noaudit
             0.66%  [g] kmem_cache_free
             0.65%  [g] glue_xts_crypt_128bit
             0.59%  [g] __d_lookup
             0.59%  [g] __audit_syscall_exit
             0.56%  [g] __memcpy
        #
      
      Then, when trying to use perf script to generate a python script and
      then process the events after adding a python hook for non-tracepoint
      events:
      
        # perf script -i perf.data.guest -g python
        generated Python script: perf-script.py
        # vim perf-script.py
        # tail -2 perf-script.py
        def process_event(param_dict):
              print(param_dict["symbol"])
        #
        # perf script -i perf.data.guest -s perf-script.py  | head
        in trace_begin
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        vmx_vmexit
        231
        #
      
      We'd see just the vmx_vmexit, i.e. the samples from the guest don't show
      up.
      
      After this patch:
      
        # perf script --guestkallsyms /wb/rhel6.kallsyms --guestmodules /wb/rhel6.modules -i perf.data.guest -s perf-script.py 2> /dev/null | head -30
        in trace_begin
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        save_args
        do_timer
        drain_array
        inode_permission
        avc_has_perm_noaudit
        run_timer_softirq
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        apic_timer_interrupt
        kvm_guest_apic_eoi_write
        run_posix_cpu_timers
        _spin_lock
        handle_pte_fault
        rcu_irq_enter
        delay_tsc
        delay_tsc
        native_read_tsc
        apic_timer_interrupt
        sys_open
        internal_add_timer
        list_del
        rcu_exit_nohz
        #
      
      Jiri Olsa noticed we need to set 'perf_guest' to true if we want to
      process guest samples and I made it be set if one of the guest files
      settings get set via the command line options added in this patch, that
      match those present in the 'perf kvm' command.
      
      We probably want to have 'perf record', 'perf report' etc to notice that
      there are guest samples and do the right thing, which is to look for
      files with some suffix that make it be associated with the guest used to
      collect the samples, i.e. if a vmlinux file is passed, we can get the
      build-id from it, if not some other identifier or simply looking for
      "kallsyms.guest", for instance, in the current directory.
      Reported-by: NMariano Pache <npache@redhat.com>
      Tested-by: NMariano Pache <npache@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
      Cc: Ali Raza <alirazabhutta.10@gmail.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Joe Mario <jmario@redhat.com>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Orran Krieger <okrieger@redhat.com>
      Cc: Ramkumar Ramachandra <artagnon@gmail.com>
      Cc: Yunlong Song <yunlong.song@huawei.com>
      Link: https://lkml.kernel.org/n/tip-d54gj64rerlxcqsrod05biwn@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      15a108af
    • A
      perf tools metric: Don't include duration_time in group · 488c3bf7
      Andi Kleen 提交于
      The Memory_BW metric generates groups including duration_time, which
      maps to a software event.
      
      For some reason this makes the group always not count.
      
      Always put duration_time outside a group when generating metrics.  It's
      always the same time, so no need to group it.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/20190628220737.13259-3-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      488c3bf7
    • A
      perf list: Avoid extra : for --raw metrics · 9c344d15
      Andi Kleen 提交于
      When printing the metrics raw, don't print : after the metricgroups.
      This helps the command line completion to complete those too.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/20190628220737.13259-2-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9c344d15
    • A
      perf vendor events intel: Metric fixes for SKX/CLX · 4df79ba3
      Andi Kleen 提交于
      - Add a missing filter for the DRAM_Latency / DRAM_Parallel_Reads metrics
      - Remove the useless PMM_* metrics from Skylake
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/20190628220737.13259-1-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4df79ba3