1. 12 1月, 2018 2 次提交
  2. 11 1月, 2018 2 次提交
    • M
      perf evsel: Fix incorrect handling of type _TERM_DRV_CFG · 2178790b
      Mathieu Poirier 提交于
      Commit ("d0565132 perf evsel: Enable type checking for
      perf_evsel_config_term types") assumes PERF_EVSEL__CONFIG_TERM_DRV_CFG
      isn't used and as such adds a BUG_ON().
      
      Since the enumeration type is used in macro ADD_CONFIG_TERM() the change
      break CoreSight trace acquisition.
      
      This patch restores the original code.
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Acked-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>
      Fixes: d0565132 ("perf evsel: Enable type checking for perf_evsel_config_term types")
      Link: http://lkml.kernel.org/r/1515617211-32024-1-git-send-email-mathieu.poirier@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2178790b
    • I
      Merge tag 'perf-core-for-mingo-4.16-20180110' of... · 1ccb8fed
      Ingo Molnar 提交于
      Merge tag 'perf-core-for-mingo-4.16-20180110' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
      
      Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
      
      - The 'perf test bpf' entry hooked a eBPF proggie to the
        SyS_epoll_wait() kernel function and expected it to be hit when calling
        the epoll_wait() libc wrapper, which changed recently, in systems such
        as Fedora 27, with the glibc wrapper calling instead the epoll_pwait()
        syscall, so switch to epoll_pwait() for both the kernel and libc
        function, getting it to work both in old and new systems (Arnaldo Carvalho de Melo)
      
      - Beautify 'gettid' syscall result in 'perf trace', and in doing so
        noticed that we need to handle namespaces in 'perf trace', will be
        dealt with in follow up patches where we'll try to figure out if
        the recent support for namespace in tools/perf/ can be used for this
        purpose as well. (Arnaldo Carvalho de Melo)
      
      - Introduce 'perf report --mmaps' and 'perf report --tasks' to show
        info present in 'perf.data' (Jiri Olsa, Arnaldo Carvalho de Melo)
      
      - Synchronize kernel <-> tooling headers wrt meltdown/spectre changes
        (Arnaldo Carvalho de Melo)
      
      - Fix a wrong offset issue when using /proc/kcore (Jin Yao)
      
      - Fix bug that prevented annotating symbols in perf.data files
        generated with 'perf record --branch-any'  (Jin Yao)
      
      - Add infrastructure to record first and last sample time to the
        perf.data file header, so that when processing all samples in
        a 'perf record' session, such as when doing build-id processing,
        or when specifically requesting that that info be recorded, use
        that in 'perf report --time', that also got support for percent
        slices in addition to absolute ones.
      
        I.e. now it is possible to ask for the samples in the 10%-20%
        time slice of a perf.data file (Jin Yao)
      
      - Enable building with libbabeltrace by default (Jiri Olsa)
      
      - Display perf_event_attr::namespaces when duping the attributes
        in verbose mode (Jiri Olsa)
      
      - Allocate context task_ctx_data for child event (Jiri Olsa)
      
      - Update comments for PERF_RECORD_ITRACE_START and PERF_RECORD_MISC_* (Jiri Olsa)
      
      - Add support for showing PERF_RECORD_LOST events in 'perf script' (Jiri Olsa)
      
      - Add 'perf report --stats' option to display quick statistics about
        metadata events (PERF_RECORD_*) i.e. what we get at the end of 'perf
        report -D' (Jiri Olsa)
      
      - Fix compile error with libunwind x86 (Wang Nan)
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1ccb8fed
  3. 10 1月, 2018 7 次提交
    • A
      tools headers: Synchronize kernel <-> tooling headers · 5d64db29
      Arnaldo Carvalho de Melo 提交于
      Two kernel headers got modified recently due to meltdown/spectre, in:
      
        a89f040f ("x86/cpufeatures: Add X86_BUG_CPU_INSECURE")
      
      which are used by tooling as well:
      
        arch/x86/include/asm/cpufeatures.h
        arch/x86/include/asm/disabled-features.h
      
      None of those changes have an effect on tooling, so do a plain copy.
      
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-qqzcs8ri3vks8cypg0puk0ae@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5d64db29
    • 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
  4. 08 1月, 2018 20 次提交
    • 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: Update PERF_RECORD_MISC_* comment for perf_event_header::misc bit 13 · 972c1488
      Jiri Olsa 提交于
      The perf_event_header::misc bit 13 is shared on different events and
      next patch is adding yet another bit 13 user.  Updating the comment to
      make it more structured and clear which events use bit 13.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      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>
      Link: http://lkml.kernel.org/r/20180107160356.28203-8-jolsa@kernel.org
      [ Update the tools/include/uapi/linux copy ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      972c1488
    • J
      perf: Return empty callchain instead of NULL · 99e818cc
      Jiri Olsa 提交于
      It simplifies the code a bit, because we dump the callchain
      Link: http://lkml.kernel.org/n/tip-uqp7qd6aif47g39glnbu95yl@git.kernel.org
      even if it's empty. With 'empty' callchain we can remove
      all the NULL-checking code paths.
      
      Original-patch-from: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.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>
      Link: http://lkml.kernel.org/r/20180107160356.28203-7-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      99e818cc
    • J
      perf: Make perf_callchain function static · 8cf7e0e2
      Jiri Olsa 提交于
      And move it to core.c, because there's no caller of this function other
      than the one in core.c
      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-6-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8cf7e0e2
    • J
      perf: Add sample_id to PERF_RECORD_ITRACE_START event comment · 81df978c
      Jiri Olsa 提交于
      Adding missing sample_id line into PERF_RECORD_ITRACE_START
      event comment.
      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-5-jolsa@kernel.org
      [ Update the tools/include/uapi/linux copy ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      81df978c
    • J
      perf: Allocate context task_ctx_data for child event · 313ccb96
      Jiri Olsa 提交于
      Currently we use perf_event_context::task_ctx_data to save and restore
      the LBR status when the task is scheduled out and in.
      
      We don't allocate it for child contexts, which results in shorter task's
      LBR stack, because we don't save the history from previous run and start
      over every time we schedule the task in.
      
      I made a test to generate samples with LBR call stack and got higher
      numbers on bigger chain depths:
      
                                  before:     after:
        LBR call chain: nr: 1       60561     498127
        LBR call chain: nr: 2           0          0
        LBR call chain: nr: 3      107030       2172
        LBR call chain: nr: 4      466685      62758
        LBR call chain: nr: 5     2307319     878046
        LBR call chain: nr: 6       48713     495218
        LBR call chain: nr: 7        1040       4551
        LBR call chain: nr: 8         481        172
        LBR call chain: nr: 9         878        120
        LBR call chain: nr: 10       2377       6698
        LBR call chain: nr: 11      28830     151487
        LBR call chain: nr: 12      29347     339867
        LBR call chain: nr: 13          4         22
        LBR call chain: nr: 14          3         53
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.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>
      Fixes: 4af57ef2 ("perf: Add pmu specific data for perf task context")
      Link: http://lkml.kernel.org/r/20180107160356.28203-4-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      313ccb96
    • 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
    • A
      perf test bpf: Use designated struct field initializers · 13cb2d0f
      Arnaldo Carvalho de Melo 提交于
      To follow standard practice in the kernel sources, documenting the
      initialization better and helping quickly finding the value for some
      field in a struct with many entries.
      
      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-syn3hz9hz7ukxlxbx5x6hv20@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      13cb2d0f
    • A
      perf test bpf: Improve message about expected samples · 6703c977
      Arnaldo Carvalho de Melo 提交于
      When failing on one of the BPF tests we were just stating:
      
        BPF filter result incorrect
      
      Add some more info to help figuring out the problem:
      
       BPF filter result incorrect, expected 56, got 0 samples
      
      This came out while investigating this failure, first seen after
      updating the kernel to the 4.15.0-rc6 tag:
      
        [root@jouet ~]# perf test bpf
        39: BPF filter               :
        39.1: Basic BPF filtering    : FAILED!
        39.2: BPF pinning            : Skip
        39.3: BPF prologue generation: Skip
        39.4: BPF relocation checker : Skip
        [root@jouet ~]#
      
      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-403npu7daupv6b2bmxliv5pk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6703c977
  5. 06 1月, 2018 9 次提交
    • I
      perf/x86/msr: Clean up the code · 9128d3ed
      Ingo Molnar 提交于
      Recent changes made a bit of an inconsistent mess out of arch/x86/events/msr.c,
      fix it:
      
       - re-align the initialization tables to be vertically aligned and readable again
      
       - harmonize comment style in terms of punctuation, capitalization and spelling
      
       - use curly braces for multi-condition branches
      
       - remove extra newlines
      
       - simplify the code a bit
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kan.liang@intel.com
      Link: http://lkml.kernel.org/r/1515169132-3980-1-git-send-email-eranian@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9128d3ed
    • S
      perf/x86/msr: Add support for MSR_IA32_THERM_STATUS · 9ae21dd6
      Stephane Eranian 提交于
      This patch adds support for the Digital Readout provided by the
      IA32_THERM_STATUS MSR (0x19C) on Intel X86 processors. The readout
      shows the number of degrees Celcius to the TCC (critical temperature)
      supported by the processor. Thus, the larger, the better.
      
      The perf_event support is provided via the msr PMU. The new
      logical event is called cpu_thermal_margin. It comes with a unit and
      snapshot files. The event shows the current temprature distance (margin).
      It is not an accumulating event. The unit is degrees C. The event
      is provided per logical CPU to make things simpler but it is the
      same for both hyper-threads sharing a physical core.
      
      $ perf stat -I 1000 -a -A -e msr/cpu_thermal_margin/
      
      This will print the temperature for all logical CPUs.
                   time CPU                counts unit events
           1.000123741 CPU0                    38 C    msr/cpu_thermal_margin/
           1.000161837 CPU1                    37 C    msr/cpu_thermal_margin/
           1.000187906 CPU2                    36 C    msr/cpu_thermal_margin/
           1.000189046 CPU3                    39 C    msr/cpu_thermal_margin/
           1.000283044 CPU4                    40 C    msr/cpu_thermal_margin/
           1.000344297 CPU5                    40 C    msr/cpu_thermal_margin/
           1.000365832 CPU6                    39 C    msr/cpu_thermal_margin/
           ...
      
      In case the temperature margin cannot be read, the reported value would be -1.
      
      Works on all processors supporting the Digital Readout (dtherm in cpuinfo)
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kan.liang@intel.com
      Link: http://lkml.kernel.org/r/1515169132-3980-1-git-send-email-eranian@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9ae21dd6
    • I
      Merge branch 'linus' into perf/core, to pick up fixes · b6815f35
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      b6815f35
    • L
      Merge tag 'for-4.15-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 89876f27
      Linus Torvalds 提交于
      Pull btrfs fixes from David Sterba:
       "We have two more fixes for 4.15, both aimed for stable.
      
        The leak fix is obvious, the second patch fixes a bug revealed by the
        refcount API, when it behaves differently than previous atomic_t and
        reports refs going from 0 to 1 in one case"
      
      * tag 'for-4.15-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes
        btrfs: Fix flush bio leak
      89876f27
    • L
      Merge tag 'xfs-4.15-fixes-10' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 12e971b6
      Linus Torvalds 提交于
      Pull XFS fixes from Darrick Wong:
       "I have just a few fixes for bugs and resource cleanup problems this
        week:
      
         - Fix resource cleanup of failed quota initialization
      
         - Fix integer overflow problems wrt s_maxbytes"
      
      * tag 'xfs-4.15-fixes-10' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: fix s_maxbytes overflow problems
        xfs: quota: check result of register_shrinker()
        xfs: quota: fix missed destroy of qi_tree_lock
      12e971b6
    • L
      Merge tag 'mfd-fixes-4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd · f842839c
      Linus Torvalds 提交于
      Pull MFD fix from Lee Jones:
       "Late bugfix to plug a leak in rtsx_pcr"
      
      * tag 'mfd-fixes-4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
        mfd: rtsx: Release IRQ during shutdown
      f842839c
    • L
      Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · abb7099d
      Linus Torvalds 提交于
      Pull  more x86 pti fixes from Thomas Gleixner:
       "Another small stash of fixes for fallout from the PTI work:
      
         - Fix the modules vs. KASAN breakage which was caused by making
           MODULES_END depend of the fixmap size. That was done when the cpu
           entry area moved into the fixmap, but now that we have a separate
           map space for that this is causing more issues than it solves.
      
         - Use the proper cache flush methods for the debugstore buffers as
           they are mapped/unmapped during runtime and not statically mapped
           at boot time like the rest of the cpu entry area.
      
         - Make the map layout of the cpu_entry_area consistent for 4 and 5
           level paging and fix the KASLR vaddr_end wreckage.
      
         - Use PER_CPU_EXPORT for per cpu variable and while at it unbreak
           nvidia gfx drivers by dropping the GPL export. The subject line of
           the commit tells it the other way around, but I noticed that too
           late.
      
         - Fix the ASM alternative macros so they can be used in the middle of
           an inline asm block.
      
         - Rename the BUG_CPU_INSECURE flag to BUG_CPU_MELTDOWN so the attack
           vector is properly identified. The Spectre mitigations will come
           with their own bug bits later"
      
      * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/pti: Rename BUG_CPU_INSECURE to BUG_CPU_MELTDOWN
        x86/alternatives: Add missing '\n' at end of ALTERNATIVE inline asm
        x86/tlb: Drop the _GPL from the cpu_tlbstate export
        x86/events/intel/ds: Use the proper cache flush method for mapping ds buffers
        x86/kaslr: Fix the vaddr_end mess
        x86/mm: Map cpu_entry_area at the same place on 4/5 level
        x86/mm: Set MODULES_END to 0xffffffffff000000
      abb7099d
    • L
      Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b03acc4c
      Linus Torvalds 提交于
      Pull EFI updates from Thomas Gleixner:
      
       - A fix for a add_efi_memmap parameter regression which ensures that
         the parameter is parsed before it is used.
      
       - Reinstate the virtual capsule mapping as the cached copy turned out
         to break Quark and other things
      
       - Remove Matt Fleming as EFI co-maintainer. He stepped back a few days
         ago. Thanks Matt for all your great work!
      
      * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
        efi/capsule-loader: Reinstate virtual capsule mapping
        x86/efi: Fix kernel param add_efi_memmap regression
      b03acc4c
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 3eac6903
      Linus Torvalds 提交于
      Pull s390 fixes from Martin Schwidefsky:
       "Four bug fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/dasd: fix wrongly assigned configuration data
        s390: fix preemption race in disable_sacf_uaccess
        s390/sclp: disable FORTIFY_SOURCE for early sclp code
        s390/pci: handle insufficient resources during dma tlb flush
      3eac6903