1. 08 Apr, 2015 17 commits
    • Jiri Olsa's avatar
      perf tests: Fix attr tests · 54a50f93
      Jiri Olsa authored
      Following commit:
        1a594131 perf: Add wakeup watermark control to the AUX area
      
      enlarged perf_event_attr, but did not updated attr tests.
      Reported-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Kaixu Xia <kaixu.xia@linaro.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Markus T Metzger <markus.t.metzger@intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Link: http://lkml.kernel.org/n/20150407171715.GA22603@krava.redhat.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      54a50f93
    • Wang Nan's avatar
      perf probe: Fix ARM 32 building error · f6c15621
      Wang Nan authored
      Commit 9b118aca ("perf probe: Fix to
      handle aliased symbols in glibc") uses an absolute format '%lx' to
      print u64 argument, which causes compiling error on ARM 32.
      
      This patch replaces it with PRIx64.
      Signed-off-by: default avatarWang Nan <wangnan0@huawei.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1428459274-138470-1-git-send-email-wangnan0@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f6c15621
    • Peter Zijlstra's avatar
      perf tools: Merge all perf_event_attr print functions · 2c5e8c52
      Peter Zijlstra authored
      Currently there's 3 (that I found) different and incomplete
      implementations of printing perf_event_attr.
      
      This is quite silly. Merge the lot.
      
      While this patch does not retain the exact form all printing that I
      found is debug output and thus it should not be critical.
      
      Also, I cannot find a single print_event_desc() caller.
      
      Pre:
      
       $ perf record -vv -e cycles -- sleep 1
       ------------------------------------------------------------
       perf_event_attr:
        type                0
        size                104
        config              0
        sample_period       4000
        sample_freq         4000
        sample_type         0x107
        read_format         0
        disabled            1    inherit             1
        pinned              0    exclusive           0
        exclude_user        0    exclude_kernel      0
        exclude_hv          0    exclude_idle        0
        mmap                1    comm                1
        mmap2               1    comm_exec           1
        freq                1    inherit_stat        0
        enable_on_exec      1    task                1
        watermark           0    precise_ip          0
        mmap_data           0    sample_id_all       1
        exclude_host        0    exclude_guest       1
        excl.callchain_kern 0    excl.callchain_user 0
        wakeup_events       0
        wakeup_watermark    0
        bp_type             0
        bp_addr             0
        config1             0
        bp_len              0
        config2             0
        branch_sample_type  0
        sample_regs_user    0
        sample_stack_user   0
        sample_regs_intr    0
       ------------------------------------------------------------
      
       $ perf evlist  -vv
       cycles: sample_freq=4000, size: 104, sample_type: IP|TID|TIME|PERIOD,
       disabled: 1, inherit: 1, mmap: 1, mmap2: 1, comm: 1, comm_exec: 1,
       freq: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1
      
       Post:
      
       $ ./perf record -vv -e cycles -- sleep 1
       ------------------------------------------------------------
       perf_event_attr:
        size                             112
        { sample_period, sample_freq }   4000
        sample_type                      IP|TID|TIME|PERIOD
        disabled                         1
        inherit                          1
        mmap                             1
        comm                             1
        freq                             1
        enable_on_exec                   1
        task                             1
        sample_id_all                    1
        exclude_guest                    1
        mmap2                            1
        comm_exec                        1
      ------------------------------------------------------------
      
       $ ./perf evlist  -vv
       cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type:
       IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq:
       1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1,
       mmap2: 1, comm_exec: 1
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20150407091150.644238729@infradead.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2c5e8c52
    • Peter Zijlstra's avatar
      perf record: Add clockid parameter · 814c8c38
      Peter Zijlstra authored
      Teach perf-record about the new perf_event_attr::{use_clockid, clockid}
      fields. Add a simple parameter to set the clock (if any) to be used for
      the events to be recorded into the data file.
      
      Since we store the entire perf_event_attr in the EVENT_DESC section we
      also already store the used clockid in the data file.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yunlong Song <yunlong.song@huawei.com>
      Link: http://lkml.kernel.org/r/20150407154851.GR23123@twins.programming.kicks-ass.net
      [ Conditionally define CLOCK_BOOTTIME, at least rhel6 doesn't have it - dsahern
        Ditto for CLOCK_MONOTONIC_RAW, sles11sp2 doesn't have it - yunlong.song ]
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      814c8c38
    • Yunlong Song's avatar
      perf sched replay: Use replay_repeat to calculate the runavg of cpu usage... · ff5f3bbd
      Yunlong Song authored
      perf sched replay: Use replay_repeat to calculate the runavg of cpu usage instead of the default value 10
      
      Since sched->replay_repeat is set to 10 as default, the sched->run_avg,
      sched->runavg_cpu_usage, and sched->runavg_parent_cpu_usage all use
      10 to calculate their value.
      
      However, the replay_repeat can be changed to other value by using -r
      option, so the calculation above should use replay_repeat to achieve
      more accurate results instead of the default value 10.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-10-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      ff5f3bbd
    • Yunlong Song's avatar
      perf sched replay: Support using -f to override perf.data file ownership · f0dd330f
      Yunlong Song authored
      Enable to use perf.data when it is not owned by current user or root.
      
      Example:
      
       $ ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 5321918 Mar 25 15:14 perf.data
       $ sudo id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       $ sudo perf sched replay -f
       run measurement overhead: 98 nsecs
       sleep measurement overhead: 52909 nsecs
       the run test took 1000015 nsecs
       the sleep test took 1054253 nsecs
       File perf.data not owned by current user or root (use -f to override)
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       $ sudo perf sched replay -f
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 40514 nsecs
       the run test took 1000003 nsecs
       the sleep test took 1056098 nsecs
       nr_run_events:        10
       nr_sleep_events:      1562
       nr_wakeup_events:     5
       task      0 (                  :1:         1), nr_events: 1
       task      1 (                  :2:         2), nr_events: 1
       task      2 (                  :3:         3), nr_events: 1
       ...
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       ------------------------------------------------------------
       #1  : 50.198, ravg: 50.20, cpu: 2335.18 / 2335.18
       #2  : 219.099, ravg: 67.09, cpu: 2835.11 / 2385.17
       #3  : 238.626, ravg: 84.24, cpu: 3278.26 / 2474.48
       #4  : 200.364, ravg: 95.85, cpu: 2977.41 / 2524.77
       #5  : 176.882, ravg: 103.96, cpu: 2801.35 / 2552.43
       #6  : 191.093, ravg: 112.67, cpu: 2813.70 / 2578.56
       #7  : 189.448, ravg: 120.35, cpu: 2809.21 / 2601.62
       #8  : 200.637, ravg: 128.38, cpu: 2849.91 / 2626.45
       #9  : 248.338, ravg: 140.37, cpu: 4380.61 / 2801.87
       #10 : 511.139, ravg: 177.45, cpu: 3077.73 / 2829.45
      
      As shown above, the -f option really works now.
      
      Besides for replay, -f option can also work for latency and map.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-9-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f0dd330f
    • Yunlong Song's avatar
      perf sched replay: Fix the EMFILE error caused by the limitation of the maximum open files · 939cda52
      Yunlong Song authored
      The soft maximum number of open files for a calling process is 1024,
      which is defined as INR_OPEN_CUR in include/uapi/linux/fs.h, and the
      hard maximum number of open files for a calling process is 4096, which
      is defined as INR_OPEN_MAX in include/uapi/linux/fs.h.
      
      Both INR_OPEN_CUR and INR_OPEN_MAX are used to limit the value of
      RLIMIT_NOFILE in include/asm-generic/resource.h.
      
      And the soft maximum number finally decides the limitation of the
      maximum files which are allowed to be opened.
      
      That is to say a process can use at most 1024 file descriptors for its
      o pened files, or an EMFILE error will happen.
      
      This error can be fixed by increasing the soft maximum number, under the
      constraint that the soft maximum number can not exceed the hard maximum
      number, or both soft and hard maximum number should be increased
      simultaneously with privilege.
      
      For perf sched replay, it uses sys_perf_event_open to create the file
      descriptor for each of the tasks in order to handle information of perf
      events.
      
      That is to say each task needs a unique file descriptor. In x86_64,
      there may be over 1024 or 4096 tasks correspoinding to the record in
      perf.data, which causes that no enough file descriptors can be used.
      
      As a result, EMFILE error happens and stops the replay process. To solve
      this problem, we adaptively increase the soft and hard maximum number of
      open files with a '-f' option.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
       $ cat /proc/sys/kernel/pid_max
       163840
       $ cat /proc/sys/fs/file-max
       6815744
       $ ulimit -Sn
       1024
       $ ulimit -Hn
       4096
      
      Before this patch:
      
       $ perf sched replay
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       Error: sys_perf_event_open() syscall returned with -1 (Too many open
       files)
      
      After this patch:
      
       $ perf sched replay
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       Error: sys_perf_event_open() syscall returned with -1 (Too many open
       files)
       Have a try with -f option
      
       $ perf sched replay -f
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       ------------------------------------------------------------
       #1  : 54.401, ravg: 54.40, cpu: 3285.21 / 3285.21
       #2  : 199.548, ravg: 68.92, cpu: 4999.65 / 3456.66
       #3  : 170.483, ravg: 79.07, cpu: 1349.94 / 3245.99
       #4  : 192.034, ravg: 90.37, cpu: 1322.88 / 3053.67
       #5  : 182.929, ravg: 99.62, cpu: 1406.51 / 2888.96
       #6  : 152.974, ravg: 104.96, cpu: 1167.54 / 2716.82
       #7  : 155.579, ravg: 110.02, cpu: 2992.53 / 2744.39
       #8  : 130.557, ravg: 112.08, cpu: 1126.43 / 2582.59
       #9  : 138.520, ravg: 114.72, cpu: 1253.22 / 2449.65
       #10 : 134.328, ravg: 116.68, cpu: 1587.95 / 2363.48
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-8-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      939cda52
    • Yunlong Song's avatar
      perf sched replay: Handle the dead halt of sem_wait when create_tasks() fails for any task · 1aff59be
      Yunlong Song authored
      Since there is sem_wait for each task in the wait_for_tasks(), e.g.
      sem_wait(&task->work_done_sem).
      
      The sem_wait can continue only when work_done_sem is greater than 0, or
      it will be blocked.
      
      For perf sched replay, one task may sem_post the work_done_sem of
      another task, which causes the work_done_sem of that task processed in a
      reasonable sequence, e.g. sem_post, sem_wait, sem_wait, sem_post...
      
      This sequence simulates the sched process of the running tasks at the
      time when perf sched record runs.
      
      As a result, all the tasks are required and their threads must be
      successfully created.
      
      If any one (task A) of the tasks fails to create its thread, then
      another task (task B), whose work_done_sem needs sem_post from that
      failed task A, may likely block itself due to seg_wait.
      
      And this is a dead halt, since task B's thread_func cannot continue at
      all.
      
      To solve this problem, perf sched replay should exit once any task fails
      to create its thread.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
      Before this patch:
      
       $ perf sched replay
       ...
       Error: sys_perf_event_open() syscall returned with -1 (Too many open
       files)
       ------------------------------------------------------------    <- dead halt
      
      After this patch:
      
       $ perf sched replay
       ...
       task   1551 (           <unknown>:         0), nr_events: 10
       Error: sys_perf_event_open() syscall returned with -1 (Too many open
       files)
       $
      
      As shown above, perf sched replay finishes the process after printing an
      error message and does not block itself.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-7-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      1aff59be
    • Yunlong Song's avatar
      perf sched replay: Fix the segmentation fault problem caused by pr_err in threads · 08097abc
      Yunlong Song authored
      The pr_err in self_open_counters() prints error message to stderr.
      Unlike stdout, stderr uses memory buffer on the stack of each calling
      process.
      
      The pr_err in self_open_counters() works in a thread called thread_func
      created in function create_tasks, which concurrently creates
      sched->nr_tasks threads.
      
      If the error happens and pr_err prints the error message in each of
      these threads, the stack size of the perf process (default is 8192
      kbytes) will quickly run out and the segmentation fault will happen
      then.
      
      To solve this problem, pr_err with self_open_counters() should be moved
      from newly created threads to the old main thread of the perf process.
      Then the pr_err can work in a stable situation without the strange
      segmentation fault problem.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
      Before this patch:
      
       $ perf sched replay
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       Segmentation fault
      
      After this patch:
      
       $ perf sched replay
       ...
       task   1549 (             :163132:    163132), nr_events: 1
       task   1550 (             :163540:    163540), nr_events: 1
       task   1551 (           <unknown>:         0), nr_events: 10
       ...
      
      As shown above, the result continues without any segmentation fault.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-6-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      08097abc
    • Yunlong Song's avatar
      perf sched replay: Realloc the memory of pid_to_task stepwise to adapt to the... · 3a423a5c
      Yunlong Song authored
      perf sched replay: Realloc the memory of pid_to_task stepwise to adapt to the different pid_max configurations
      
      Although the memory of pid_to_task can be allocated via calloc according
      to the value of /proc/sys/kernel/pid_max, it cannot handle the case when
      pid_max is changed after 'perf sched record' has created its perf.data.
      
      If the new pid_max configured in 'perf sched replay' is smaller than the
      old pid_max configured in 'perf sched record', then it will cause the
      assertion failure problem.
      
      To solve this problem, we realloc the memory of pid_to_task stepwise
      once the passed-in pid parameter in register_pid is larger than the
      current pid_max.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
       $ cat /proc/sys/kernel/pid_max
       163840
       $ perf sched record ls
       $ echo 5000 > /proc/sys/kernel/pid_max
       $ cat /proc/sys/kernel/pid_max
       5000
      
      Before this patch:
      
       $ perf sched replay
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 55356 nsecs
       the run test took 1000011 nsecs
       the sleep test took 1060940 nsecs
       perf: builtin-sched.c:337: register_pid: Assertion `!(pid >= (unsigned
       long)pid_max)' failed.
       Aborted
      
      After this patch:
      
       $ perf sched replay
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 55611 nsecs
       the run test took 1000026 nsecs
       the sleep test took 1060486 nsecs
       nr_run_events:        10
       nr_sleep_events:      1562
       nr_wakeup_events:     5
       task      0 (                  :1:         1), nr_events: 1
       task      1 (                  :2:         2), nr_events: 1
       task      2 (                  :3:         3), nr_events: 1
       task      3 (                  :5:         5), nr_events: 1
       ...
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-5-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3a423a5c
    • Yunlong Song's avatar
      perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the... · cb06ac25
      Yunlong Song authored
      perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max
      
      The current memory allocation of struct task_desc *pid_to_task[MAX_PID]
      is in a permanent and preset way, and it has two problems:
      
      Problem 1: If the pid_max, which is the max number of pids in the
      system, is much smaller than MAX_PID (1024*1000), then it causes a waste
      of stack memory. This may happen in the case where the number of cpu
      cores is much smaller than 1000.
      
      Problem 2: If the pid_max is changed from the default value to a value
      larger than MAX_PID, then it will cause assertion failure problem. The
      maximum value of pid_max can be set to pid_max_max (see pidmap_init
      defined in kernel/pid.c), which equals to PID_MAX_LIMIT. In x86_64,
      PID_MAX_LIMIT is 4*1024*1024 (defined in include/linux/threads.h). This
      value is much larger than MAX_PID, and will take up 32768 Kbytes
      (4*1024*1024*8/1024) for memory allocation of pid_to_task, which is much
      larger than the default 8192 Kbytes of the stack size of calling
      process.
      
      Due to these two problems, we use calloc to allocate the memory of
      pid_to_task dynamically.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
       $ cat /proc/sys/kernel/pid_max
       163840
       $ echo 1025000 > /proc/sys/kernel/pid_max
       $ cat /proc/sys/kernel/pid_max
       1025000
      
      Run some applications until the pid of some process is greater than
      the value of MAX_PID (1024*1000).
      
      Before this patch:
      
       $ perf sched replay
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 55480 nsecs
       the run test took 1000008 nsecs
       the sleep test took 1063151 nsecs
       perf: builtin-sched.c:330: register_pid: Assertion `!(pid >= 1024000)'
       failed.
       Aborted
      
      After this patch:
      
       $ perf sched replay
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 55435 nsecs
       the run test took 1000004 nsecs
       the sleep test took 1059312 nsecs
       nr_run_events:        10
       nr_sleep_events:      1562
       nr_wakeup_events:     5
       task      0 (                  :1:         1), nr_events: 1
       task      1 (                  :2:         2), nr_events: 1
       task      2 (                  :3:         3), nr_events: 1
       task      3 (                  :5:         5), nr_events: 1
       ...
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-4-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      cb06ac25
    • Yunlong Song's avatar
      perf sched replay: Increase the MAX_PID value to fix assertion failure problem · a35e27d0
      Yunlong Song authored
      Current MAX_PID is only 65536, which will cause assertion failure problem
      when CPU cores are more than 64 in x86_64.
      
      This is because the pid_max value in x86_64 is at least
      PIDS_PER_CPU_DEFAULT * num_possible_cpus() (see function pidmap_init
      defined in kernel/pid.c), where PIDS_PER_CPU_DEFAULT is 1024 (defined in
      include/linux/threads.h).
      
      Thus for MAX_PID = 65536, the correspoinding CPU cores are
      65536/1024=64.  This is obviously not enough at all for x86_64, and will
      cause an assertion failure problem due to BUG_ON(pid >= MAX_PID) in the
      codes.
      
      We increase MAX_PID value from 65536 to 1024*1000, which can be used in
      x86_64 with 1000 cores.
      
      This number is finally decided according to the limitation of stack size
      of calling process.
      
      Use 'ulimit -a', the result shows the stack size of any process is 8192
      Kbytes, which is defined in include/uapi/linux/resource.h (#define
      _STK_LIM (8*1024*1024)).
      
      Thus we choose a large enough value for MAX_PID, and make it satisfy to
      the limitation of the stack size, i.e., making the perf process take up
      a memory space just smaller than 8192 Kbytes.
      
      We have calculated and tested that 1024*1000 is OK for MAX_PID.
      
      This means perf sched replay can now be used with at most 1000 cores in
      x86_64 without any assertion failure problem.
      
      Example:
      
      Test environment: x86_64 with 160 cores
      
       $ cat /proc/sys/kernel/pid_max
       163840
      
      Before this patch:
      
       $ perf sched replay
       run measurement overhead: 240 nsecs
       sleep measurement overhead: 55379 nsecs
       the run test took 1000004 nsecs
       the sleep test took 1059424 nsecs
       perf: builtin-sched.c:330: register_pid: Assertion `!(pid >= 65536)'
       failed.
       Aborted
      
      After this patch:
      
       $ perf sched replay
       run measurement overhead: 221 nsecs
       sleep measurement overhead: 55397 nsecs
       the run test took 999920 nsecs
       the sleep test took 1053313 nsecs
       nr_run_events:        10
       nr_sleep_events:      1562
       nr_wakeup_events:     5
       task      0 (                  :1:         1), nr_events: 1
       task      1 (                  :2:         2), nr_events: 1
       task      2 (                  :3:         3), nr_events: 1
       task      3 (                  :5:         5), nr_events: 1
       ...
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-3-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a35e27d0
    • Yunlong Song's avatar
      perf sched replay: Use struct task_desc instead of struct task_task for correct meaning · 0755bc4d
      Yunlong Song authored
      There is no struct task_task at all, thus it is a typo error in the old
      commits, now fix it to what it should be in order to avoid unnecessary
      misunderstanding.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427809596-29559-2-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      0755bc4d
    • Jiri Olsa's avatar
      perf kmem: Respect -i option · 28939e1a
      Jiri Olsa authored
      Currently the perf kmem does not respect -i option.
      
      Initializing the file.path properly after options get parsed.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1428298576-9785-2-git-send-email-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      28939e1a
    • Namhyung Kim's avatar
      tools lib traceevent: Honor operator priority · 3201f0dc
      Namhyung Kim authored
      Currently it ignores operator priority and just sets processed args as a
      right operand.  But it could result in priority inversion in case that
      the right operand is also a operator arg and its priority is lower.
      
      For example, following print format is from new kmem events.
      
        "page=%p", REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)
      
      But this was treated as below:
      
        REC->pfn != ((null - 1UL) ? ((struct page *)0xffffea0000000000UL + REC->pfn) : (void *) 0)
      
      In this case, the right arg was '?' operator which has lower priority.
      But it just sets the whole arg so making the output confusing - page was
      always 0 or 1 since that's the result of logical operation.
      
      With this patch, it can handle it properly like following:
      
        ((REC->pfn != (null - 1UL)) ? ((struct page *)0xffffea0000000000UL + REC->pfn) : (void *) 0)
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1428298576-9785-10-git-send-email-namhyung@kernel.org
      [ Replaced 'swap' with 'rotate' in a comment as requested by Steve and agreed by Namhyung ]
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3201f0dc
    • Wang Nan's avatar
      perf kmaps: Check kmaps to make code more robust · ba92732e
      Wang Nan authored
      This patch add checks in places where map__kmap is used to get kmaps
      from struct kmap.
      
      Error messages are added at map__kmap to warn invalid accessing of kmap
      (for the case of !map->dso->kernel, kmap(map) does not exists at all).
      
      Also, introduces map__kmaps() to warn uninitialized kmaps.
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarWang Nan <wangnan0@huawei.com>
      Cc: pi3orama@163.com
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Link: http://lkml.kernel.org/r/1428394966-131044-2-git-send-email-wangnan0@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      ba92732e
    • He Kuang's avatar
      perf evlist: Fix inverted logic in perf_mmap__empty · 8ea92ceb
      He Kuang authored
      perf_evlist__mmap_consume() uses perf_mmap__empty() to judge whether
      perf_mmap is empty and can be released. But the result is inverted so
      fix it.
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1428399071-7141-1-git-send-email-hekuang@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      8ea92ceb
  2. 03 Apr, 2015 1 commit
    • Ingo Molnar's avatar
      Merge tag 'perf-core-for-mingo' of... · 6645f318
      Ingo Molnar authored
      Merge tag 'perf-core-for-mingo' 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:
      
      User visible changes:
      
        - Support unnamed union/structure members data collection in 'perf probe'. (Masami Hiramatsu)
      
        - Support missing -f to override perf.data file ownership. (Yunlong Song)
      
      Infrastructure changes:
      
        - No need to lookup thread twice when processing samples in 'perf script'. (Arnaldo Carvalho de Melo)
      
        - No need to pass thread twice to the scripting callbacks. (Arnaldo Carvalho de Melo)
      
        - No need to pass thread twice to the db-export facility. (Arnaldo Carvalho de Melo)
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6645f318
  3. 02 Apr, 2015 22 commits
    • Yunlong Song's avatar
      perf data: Support using -f to override perf.data file ownership for 'convert' · bd05954b
      Yunlong Song authored
      Enable perf data convert to use perf.data when it is not owned by
      current user or root.
      
      Example:
      
       # perf record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 28260 Apr  2 17:35 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf data convert --to-ctf=./ctf-data/
       File perf.data not owned by current user or root (use -f to override)
       # perf data convert --to-ctf=./ctf-data/ -f
         Error: unknown switch `f'
      
        usage: perf data convert [<options>]
      
           -v, --verbose         be more verbose
           -i, --input <file>    input file name
               --to-ctf ...      Convert to CTF format
      
      After this patch:
      
       # perf data convert --to-ctf=./ctf-data/
       File perf.data not owned by current user or root (use -f to override)
       # perf data convert --to-ctf=./ctf-data/ -f
       # ls ctf-data/
       metadata  perf_stream_0
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-11-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      bd05954b
    • Yunlong Song's avatar
      perf trace: Support using -f to override perf.data file ownership · e366a6d8
      Yunlong Song authored
      Enable perf trace to use perf.data when it is not owned by current user
      or root.
      
      Example:
      
       # perf trace record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 4153101 Apr  2 15:28 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf trace -i perf.data
       File perf.data not owned by current user or root (use -f to override)
       # perf trace -i perf.data -f
         Error: unknown switch `f'
      
        usage: perf trace [<options>] [<command>]
           or: perf trace [<options>] -- <command> [<options>]
           or: perf trace record [<options>] [<command>]
           or: perf trace record [<options>] -- <command> [<options>]
      
               --event <event>   event selector. use 'perf list' to list
       						  available events
               --comm            show the thread COMM next to its id
               --tool_stats      show tool stats
           -e, --expr <expr>     list of events to trace
           -o, --output <file>   output file name
           -i, --input <file>    Analyze events in file
           -p, --pid <pid>       trace events on existing process id
           -t, --tid <tid>       trace events on existing thread id
               --filter-pids <float>
        ...
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf trace -i perf.data
       File perf.data not owned by current user or root (use -f to override)
       # perf trace -i perf.data -f
       0.056 ( 0.002 ms): ls/47325 brk(                                 ...
       0.108 ( 0.018 ms): ls/47325 mmap(len: 4096, prot: READ|WRITE,    ...
       0.145 ( 0.013 ms): ls/47325 access(filename: 0x7f31259a0eb0,     ...
       0.172 ( 0.008 ms): ls/47325 open(filename: 0x7fffeb9a0d00,       ...
       0.180 ( 0.004 ms): ls/47325 stat(filename: 0x7fffeb9a0d00,       ...
       0.185 ( 0.004 ms): ls/47325 open(filename: 0x7fffeb9a0d00,       ...
       0.189 ( 0.003 ms): ls/47325 stat(filename: 0x7fffeb9a0d00,       ...
       0.195 ( 0.004 ms): ls/47325 open(filename: 0x7fffeb9a0d00,       ...
       0.199 ( 0.002 ms): ls/47325 stat(filename: 0x7fffeb9a0d00,       ...
       0.205 ( 0.004 ms): ls/47325 open(filename: 0x7fffeb9a0d00,       ...
       0.211 ( 0.004 ms): ls/47325 stat(filename: 0x7fffeb9a0d00,       ...
       0.220 ( 0.007 ms): ls/47325 open(filename: 0x7f312599e8ff,       ...
       ...
       ...
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-10-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e366a6d8
    • Yunlong Song's avatar
      perf timechart: Support using -f to override perf.data file ownership · 44f7e432
      Yunlong Song authored
      Enable perf timechart to use perf.data when it is not owned by current
      user or root.
      
      Example:
      
       # perf timechart record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 5471744 Apr  2 15:15 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf timechart
       File perf.data not owned by current user or root (use -f to override)
       # perf timechart -f
         Error: unknown switch `f'
      
        usage: perf timechart [<options>] {record}
      
           -i, --input <file>    input file name
           -o, --output <file>   output file name
           -w, --width <n>       page width
               --highlight <duration or task name>
                                 highlight tasks. Pass duration in ns or process name.
           -P, --power-only      output power data only
           -T, --tasks-only      output processes data only
           -p, --process <process>
                                 process selector. Pass a pid or process name.
               --symfs <directory>
                                 Look for files with symbols relative to this directory
           -n, --proc-num <n>    min. number of tasks to print
           -t, --topology        sort CPUs according to topology
               --io-skip-eagain  skip EAGAIN errors
               --io-min-time <time>
                                 all IO faster than min-time will visually appear longer
               --io-merge-dist <time>
                                 merge events that are merge-dist us apart
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf timechart
       File perf.data not owned by current user or root (use -f to override)
       # perf timechart -f
       Written 0.0 seconds of trace to output.svg.
       # cat output.svg
       <?xml version="1.0" standalone="no"?>
       <!DOCTYPE svg SYSTEM "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
       <svg width="1000" height="10110" version="1.1" xmlns="http://www.w3.org/2000/svg">
       <defs>
         <style type="text/css">
           <![CDATA[
             rect          { stroke-width: 1; }
       ...
       ...
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-9-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      44f7e432
    • Yunlong Song's avatar
      perf script: Support using -f to override perf.data file ownership · 06af0f2c
      Yunlong Song authored
      Enable perf script to use perf.data when it is not owned by current user
      or root. Change the short option name of --fields to -F to avoid confusion
      with --force.
      
      Example:
      
       # perf record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 28360 Apr  2 14:53 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf script
       File perf.data not owned by current user or root (use -f to override)
       # perf script -f
         Error: switch `f' requires a value
      
        usage: perf script [<options>]
           or: perf script [<options>] record <script> [<record-options>] <command>
           or: perf script [<options>] report <script> [script-args]
           or: perf script [<options>] <script> [<record-options>] <command>
           or: perf script [<options>] <top-script> [script-args]
      
           -f, --fields <str>    comma separated output fields prepend with
           'type:'. Valid types: hw,sw,trace,raw. Fields:
           comm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,period
      
      As shown above, the -f option does not work at all. And -f is already
      taken up by --fields, which makes --force confused, so change the short
      option name of --fields to -F like what other perf commands do (e.g.
      perf report -F) and use -f as the short option name of --force.
      
      After this patch:
      
       # perf script
       File perf.data not owned by current user or root (use -f to override)
       # perf script -f
       :41298 41298 2590086.564226:          1 cycles:  ffffffff8103efc6
       native_write_msr_safe ([kernel.kallsyms])
       :41298 41298 2590086.564244:          1 cycles:  ffffffff8103efc6
       native_write_msr_safe ([kernel.kallsyms])
       :41298 41298 2590086.564249:          7 cycles:  ffffffff8103efc6
       native_write_msr_safe ([kernel.kallsyms])
       :41298 41298 2590086.564255:        176 cycles:  ffffffff8103efc6
       native_write_msr_safe ([kernel.kallsyms])
           ls 41298 2590086.567346:       4059 cycles:  ffffffff8105a592
           raise_softirq ([kernel.kallsyms])
           ls 41298 2590086.567353:       3717 cycles:  ffffffff8105a592
           raise_softirq ([kernel.kallsyms])
           ls 41298 2590086.567358:      63058 cycles:  ffffffff8105a592
           raise_softirq ([kernel.kallsyms])
           ls 41298 2590086.567448:    1706255 cycles:            406ae0
           [unknown] (/usr/bin/ls)
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-8-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      06af0f2c
    • Yunlong Song's avatar
      perf mem: Support using -f to override perf.data file ownership · 62a1a63a
      Yunlong Song authored
      Enable perf mem to use perf.data when it is not owned by current user or
      root.
      
      Example:
      
       # perf mem -t load record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 16392 Apr  2 14:34 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf mem -D report
       File perf.data not owned by current user or root (use -f to override)
       # perf mem -D -f report
         Error: unknown switch `f'
      
        usage: perf mem [<options>] {record|report}
      
           -t, --type <type>     memory operations(load,store) Default load,store
           -D, --dump-raw-samples
                                 dump raw samples in ASCII
           -U, --hide-unresolved
                                 Only display entries resolved to a symbol
           -i, --input <file>    input file name
           -C, --cpu <cpu>       list of cpus to profile
           -x, --field-separator <separator>
                                 separator for columns, no spaces will be added
                                 between columns '.' is reserved.
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf mem -D report
       File perf.data not owned by current user or root (use -f to override)
       # perf mem -D -f report
       # PID, TID, IP, ADDR, LOCAL WEIGHT, DSRC, SYMBOL
       39095 39095 0xffffffff81127e40 0x016ffff887f45148338 8 0x68100142
       /proc/kcore:perf_event_aux
       39095 39095 0xffffffff8100a3fe 0xffff89007f8cb7d0 6 0x68100142
       /proc/kcore:native_sched_clock
       39095 39095 0xffffffff81309139 0xffff88bf44c9ded8 6 0x68100142
       /proc/kcore:acpi_map_lookup
       39095 39095 0xffffffff810f8c4c 0xffff89007f8ccd88 6 0x68100142
       /proc/kcore:rcu_nmi_exit
       39095 39095 0xffffffff81136346 0xffff88fea995dd50 6 0x68100142
       /proc/kcore:unlock_page
       39095 39095 0xffffffff812a64a2 0xffff88fea995dcc8 6 0x68100142
       /proc/kcore:half_md4_transform
       39095 39095 0x7f0cf877c7e9 0x25dfb94 6 0x68100142
       /lib64/libc-2.19.so:__readdir64
       39095 39095 0x7f0cf87575a3 0x7f0cf9163731 6 0x68100142
       /lib64/libc-2.19.so:__strcoll_l
       39095 39095 0xffffffff8116910e 0xffffea01c1bfbd50 23 0x68100242
       /proc/kcore:page_remove_rmap
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-7-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      62a1a63a
    • Yunlong Song's avatar
      perf lock: Support using -f to override perf.data file ownership · c4ac732a
      Yunlong Song authored
      Enable perf lock to use perf.data when it is not owned by current user
      or root.
      
      Example:
      
       # perf lock record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 4880686 Apr  2 14:14 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf lock report
       File perf.data not owned by current user or root (use -f to override)
       Initializing perf session failed
       # perf lock report -f
         Error: unknown switch `f'
      
        usage: perf lock report [<options>]
      
           -k, --key <acquired>  key for sorting (acquired / contended /
           avg_wait / wait_total / wait_max / wait_min)
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf lock report
       File perf.data not owned by current user or root (use -f to override)
       Initializing perf session failed
       # perf lock report -f
                      Name   acquired  contended   avg wait (ns) total wait (ns) ...
      
       &ldata->output_l...        128          0               0               0 ...
                &ctx->lock        114          0               0               0 ...
               &p->pi_lock        112          0               0               0 ...
       &(&pool->lock)->...        112          0               0               0 ...
       &(&dentry->d_loc...         70          0               0               0 ...
       &(&newf->file_lo...         62          0               0               0 ...
       &(&fs->lock)->rl...         43          0               0               0 ...
       ...
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-6-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c4ac732a
    • Yunlong Song's avatar
      perf kvm: Support using -f to override perf.data.guest file ownership · 8cc5ec1f
      Yunlong Song authored
      Enable perf kvm to use perf.data.guest when it is not owned by current
      user or root.
      
      Example:
      
       # perf kvm stat record ls
       # chown Yunlong.Song:Yunlong.Song perf.data.guest
       # ls -al perf.data.guest
       -rw------- 1 Yunlong.Song Yunlong.Song 4128937 Apr  2 11:05 perf.data.guest
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf kvm stat report
       File perf.data.guest not owned by current user or root (use -f to override)
       Initializing perf session failed
       # perf kvm stat report -f
         Error: unknown switch `f'
      
        usage: perf kvm stat report [<options>]
      
               --event <report event>
                                 event for reporting: vmexit, mmio (x86 only),
                                 ioport (x86 only)
               --vcpu <n>        vcpu id to report
           -k, --key <sort-key>  key for sorting: sample(sort by samples
       						   number) time (sort by avg time)
           -p, --pid <pid>       analyze events only for given process id(s)
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf kvm stat report
       File perf.data.guest not owned by current user or root (use -f to override)
       Initializing perf session failed
       # perf kvm stat report -f
       Analyze events for all VMs, all VCPUs:
      
         VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time   Avg time
      
       Total Samples:0, Total events handled time:0.00us.
      
      As shown above, the -f option really works now. Since we have not
      launched any KVM related process, the result shows 0 sample here.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-5-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      8cc5ec1f
    • Yunlong Song's avatar
      perf kmem: Support using -f to override perf.data file ownership · d1eeb77c
      Yunlong Song authored
      Enable perf kmem to use perf.data when it is not owned by current user
      or root.
      
      Example:
      
       # perf kmem record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 5315665 Apr  2 10:54 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf kmem stat
       File perf.data not owned by current user or root (use -f to override)
       # perf kmem stat -f
         Error: unknown switch `f'
      
        usage: perf kmem [<options>] {record|stat}
      
           -i, --input <file>    input file name
           -v, --verbose         be more verbose (show symbol address, etc)
               --caller          show per-callsite statistics
               --alloc           show per-allocation statistics
           -s, --sort <key[,key2...]>
                                 sort by keys: ptr, call_site, bytes, hit,
                                 pingpong, frag
           -l, --line <num>      show n lines
               --raw-ip          show raw ip instead of symbol
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf kmem stat
       File perf.data not owned by current user or root (use -f to override)
       # perf kmem stat -f
       SUMMARY
       =======
       Total bytes requested: 437599
       Total bytes allocated: 615472
       Total bytes wasted on internal fragmentation: 177873
       Internal fragmentation: 28.900259%
       Cross CPU allocations: 6/1192
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-4-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d1eeb77c
    • Yunlong Song's avatar
      perf inject: Support using -f to override perf.data file ownership · ccaa474c
      Yunlong Song authored
      Enable perf inject to use perf.data when it is not owned by current user
      or root.
      
      Example:
      
       # perf record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 28260 Apr  2 10:37 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf inject -v -b -i perf.data -o perf.data.new
       File perf.data not owned by current user or root (use -f to override)
       # perf inject -v -b -i perf.data -o perf.data.new -f
         Error: unknown switch `f'
      
        usage: perf inject [<options>]
      
           -b, --build-ids       Inject build-ids into the output stream
           -i, --input <file>    input file name
           -o, --output <file>   output file name
           -s, --sched-stat      Merge sched-stat and sched-switch for getting
           events where and how long tasks slept
           -v, --verbose         be more verbose (show build ids, etc)
               --kallsyms <file>
                                 kallsyms pathname
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf inject -v -b -i perf.data -o perf.data.new
       File perf.data not owned by current user or root (use -f to override)
       # perf inject -v -b -i perf.data -o perf.data.new -f
       build id event received for [kernel.kallsyms]:
       f6dcb66d8b98f1c0d9eb87bf043444b69f91d30c
       symsrc__init: cannot get elf header.
       Looking at the vmlinux_path (7 entries long)
       Using /proc/kcore for kernel object code
       Using /proc/kallsyms for symbols
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-3-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      ccaa474c
    • Yunlong Song's avatar
      perf evlist: Support using -f to override perf.data file ownership · 9e3b6ec1
      Yunlong Song authored
      Enable perf evlist to use perf.data when it is not owned by current user
      or root.
      
      Example:
      
       # perf record ls
       # chown Yunlong.Song:Yunlong.Song perf.data
       # ls -al perf.data
       -rw------- 1 Yunlong.Song Yunlong.Song 28260 Apr  2 10:18 perf.data
       # id
       uid=0(root) gid=0(root) groups=0(root),64(pkcs11)
      
      Before this patch:
      
       # perf evlist
       File perf.data not owned by current user or root (use -f to override)
       # perf evlist -f
         Error: unknown switch `f'
      
        usage: perf evlist [<options>]
      
           -i, --input <file>    Input file name
           -F, --freq            Show the sample frequency
           -v, --verbose         Show all event attr details
           -g, --group           Show event group information
      
      As shown above, the -f option does not work at all.
      
      After this patch:
      
       # perf evlist
       File perf.data not owned by current user or root (use -f to override)
       # perf evlist -f
       cycles
      
      As shown above, the -f option really works now.
      Signed-off-by: default avatarYunlong Song <yunlong.song@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1427982439-27388-2-git-send-email-yunlong.song@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9e3b6ec1
    • Masami Hiramatsu's avatar
      perf probe: Fix to track down unnamed union/structure members · c7273835
      Masami Hiramatsu authored
      Fix 'perf probe' to track down unnamed union/structure members.
      
      perf probe did not track down the tree of unnamed union/structure
      members, since it just failed to find given "name" in a parent
      structure/union.  To solve this issue, I've introduced 2 changes.
      
      - Fix die_find_member() to track down the type-DIE if it is
        unnamed, and if it contains the specified member, returns the
        unnamed member.
        (note that we don't return found member, since unnamed member
         has the offset in the parent structure)
      - Fix convert_variable_fields() to track down the unnamed union/
        structure (one-by-one).
      
      With this patch, perf probe can access unnamed fields:
        -----
        #./perf probe -nfx ./perf lock__delete ops 'locked_ops=ops->locked.ops'
        Added new event:
          probe_perf:lock__delete (on lock__delete in /home/mhiramat/ksrc/linux-3/tools/perf/perf with ops locked_ops=ops->locked.ops)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe_perf:lock__delete -aR sleep 1
        -----
      Reported-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Report-Link: https://lkml.org/lkml/2015/3/5/431Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150402073312.14482.37942.stgit@localhost.localdomainSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c7273835
    • Arnaldo Carvalho de Melo's avatar
      perf db-export: No need to have ->thread twice in struct export_sample · b83e868d
      Arnaldo Carvalho de Melo authored
      As it comes from address_location->thread, that is already stored as
      export_sample->al, where the thread can be obtained.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20150402141542.GA9630@kernel.org
      Link: http://lkml.kernel.org/n/tip-bzotbl4epoztw0jd6sm2stpf@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b83e868d
    • Arnaldo Carvalho de Melo's avatar
      perf db-export: No need to pass thread twice to db_export__sample · 7327259d
      Arnaldo Carvalho de Melo authored
      As it is available via another parameter, address_location->thread.
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: lkml.kernel.org/r/551D08F8.3040706@intel.com
      Link: http://lkml.kernel.org/n/tip-6dbn0tcm9hyv92g7h3zj2dbt@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      7327259d
    • Arnaldo Carvalho de Melo's avatar
      perf scripting: No need to pass thread twice to the scripting callbacks · f9d5d549
      Arnaldo Carvalho de Melo authored
      It is already in the addr_location, so remove the redundant 'thread'
      parameter from the callback signatures.
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1427906210-10519-3-git-send-email-acme@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f9d5d549
    • Arnaldo Carvalho de Melo's avatar
      perf script: No need to lookup thread twice · 79628f2c
      Arnaldo Carvalho de Melo authored
      We get the thread when we call perf_event__preprocess_sample(), no need
      to do it before that.
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1427906210-10519-2-git-send-email-acme@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      79628f2c
    • Ingo Molnar's avatar
      perf/x86/intel/pt: Fix the 32-bit build · 2e54a5bd
      Ingo Molnar authored
      On a 32-bit build I got:
      
        arch/x86/kernel/cpu/perf_event_intel_pt.c:413:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
        arch/x86/kernel/cpu/perf_event_intel_bts.c:162:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      
      Fix it. The code should probably be (re-)tested on 32-bit systems to make
      sure all is fine.
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kaixu Xia <kaixu.xia@linaro.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: adrian.hunter@intel.com
      Cc: kan.liang@intel.com
      Cc: markus.t.metzger@intel.com
      Cc: mathieu.poirier@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2e54a5bd
    • Andi Kleen's avatar
      perf/x86/intel: Avoid rewriting DEBUGCTL with the same value for LBRs · cd1f11de
      Andi Kleen authored
      perf with LBRs on has a tendency to rewrite the DEBUGCTL MSR with
      the same value. Add a little optimization to skip the unnecessary
      write.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1426871484-21285-2-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cd1f11de
    • Andi Kleen's avatar
      perf/x86/intel: Streamline LBR MSR handling in PMI · 1a78d937
      Andi Kleen authored
      The perf PMI currently does unnecessary MSR accesses when
      LBRs are enabled. We use LBR freezing, or when in callstack
      mode force the LBRs to only filter on ring 3.
      
      So there is no need to disable the LBRs explicitely in the
      PMI handler.
      
      Also we always unnecessarily rewrite LBR_SELECT in the LBR
      handler, even though it can never change.
      
       5)               |  /* write_msr: MSR_LBR_SELECT(1c8), value 0 */
       5)               |  /* read_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
       5)               |  /* write_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
       5)               |  /* write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 70000000f */
       5)               |  /* write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 */
       5)               |  /* write_msr: MSR_LBR_SELECT(1c8), value 0 */
       5)               |  /* read_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
       5)               |  /* write_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
      
      This patch:
      
        - Avoids disabling already frozen LBRs unnecessarily in the PMI
        - Avoids changing LBR_SELECT in the PMI
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1426871484-21285-1-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1a78d937
    • Andi Kleen's avatar
      perf/x86: Only dump PEBS register when PEBS has been detected · 15fde110
      Andi Kleen authored
      Technically PEBS_ENABLED is only guaranteed to exist when we
      detected PEBS. So add a check for this to the PMU dump function.
      I don't think it can happen on a real CPU, but could in a VM.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1425059312-18217-4-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      15fde110
    • Andi Kleen's avatar
      perf/x86: Dump DEBUGCTL in PMU dump · da3e606d
      Andi Kleen authored
      LBRs and LBR freezing are controlled through the DEBUGCTL MSR. So
      dump the state of DEBUGCTL too when dumping the PMU state.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1425059312-18217-3-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      da3e606d
    • Andi Kleen's avatar
      perf/x86/intel: Reset more state in PMU reset · 8882edf7
      Andi Kleen authored
      The PMU reset code didn't quite keep up with newer PMU features.
      Improve it a bit to really reset a modern PMU:
      
        - Clear all overflow status
        - Clear LBRs and freezing state
        - Disable fixed counters too
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1425059312-18217-2-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8882edf7
    • Stephane Eranian's avatar
      perf/x86/intel: Make the HT bug workaround conditional on HT enabled · b37609c3
      Stephane Eranian authored
      This patch disables the PMU HT bug when Hyperthreading (HT)
      is disabled. We cannot do this test immediately when perf_events
      is initialized. We need to wait until the topology information
      is setup properly. As such, we register a later initcall, check
      the topology and potentially disable the workaround. To do this,
      we need to ensure there is no user of the PMU. At this point of
      the boot, the only user is the NMI watchdog, thus we disable
      it during the switch and re-enable it right after.
      
      Having the workaround disabled when it is not needed provides
      some benefits by limiting the overhead is time and space.
      The workaround still ensures correct scheduling of the corrupting
      memory events (0xd0, 0xd1, 0xd2) when HT is off. Those events
      can only be measured on counters 0-3. Something else the current
      kernel did not handle correctly.
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: bp@alien8.de
      Cc: jolsa@redhat.com
      Cc: kan.liang@intel.com
      Cc: maria.n.dimakopoulou@gmail.com
      Link: http://lkml.kernel.org/r/1416251225-17721-13-git-send-email-eranian@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b37609c3