1. 27 5月, 2015 2 次提交
  2. 15 5月, 2015 1 次提交
  3. 13 5月, 2015 9 次提交
  4. 09 5月, 2015 1 次提交
  5. 05 5月, 2015 1 次提交
  6. 01 5月, 2015 2 次提交
  7. 30 4月, 2015 1 次提交
    • M
      Revert "powerpc/tm: Abort syscalls in active transactions" · 68fc378c
      Michael Ellerman 提交于
      This reverts commit feba4036.
      
      Although the principle of this change is good, the implementation has a
      few issues.
      
      Firstly we can sometimes fail to abort a syscall because r12 may have
      been clobbered by C code if we went down the virtual CPU accounting
      path, or if syscall tracing was enabled.
      
      Secondly we have decided that it is safer to abort the syscall even
      earlier in the syscall entry path, so that we avoid the syscall tracing
      path when we are transactional.
      
      So that we have time to thoroughly test those changes we have decided to
      revert this for this merge window and will merge the fixed version in
      the next window.
      
      NB. Rather than reverting the selftest we just drop tm-syscall from
      TEST_PROGS so that it's not run by default.
      
      Fixes: feba4036 ("powerpc/tm: Abort syscalls in active transactions")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      68fc378c
  8. 28 4月, 2015 5 次提交
    • P
      perf bench numa: Fix immediate meeting of convergence condition · 1d90a685
      Petr Holasek 提交于
      This patch fixes the race in the beginning of benchmark run when some
      threads hasn't got assigned curr_cpu yet so they don't occur in
      nodes-of-process stats and benchmark concludes that all remaining
      threads are converged already.
      
      The race can be reproduced with small amount of threads and some bigger
      amount of shared process memory, e.g. one process, two threads and 5GB
      of process memory.
      Signed-off-by: NPetr Holasek <pholasek@redhat.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/1429198699-25039-4-git-send-email-pholasek@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1d90a685
    • P
      perf bench numa: Fixes of --quiet argument · 24f1ced1
      Petr Holasek 提交于
      Corrected description and fixed function of --quiet argument.
      Signed-off-by: NPetr Holasek <pholasek@redhat.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/1429198699-25039-2-git-send-email-pholasek@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      24f1ced1
    • D
      perf bench futex: Fix hung wakeup tasks after requeueing · 052b0f6e
      Davidlohr Bueso 提交于
      The futex-requeue benchmark can hang because of missing wakeups once the
      benchmark is done, ie:
      
      [Run 1]: Requeued 1024 of 1024 threads in 0.3290 ms
      perf: couldn't wakeup all tasks (135/1024)
      
      This bug, while perhaps suggesting missing wakeups in kernel futex code,
      is merely a consequence of the crappy FUTEX_CMP_REQUEUE man page,
      incorrectly mentioning that the number of requeued tasks is in fact
      returned, not the wakeups.
      
      This patch acknowledges this and updates the corresponding futex_wake
      code around it.
      Signed-off-by: NDavidlohr Bueso <dbueso@suse.de>
      Cc: Mel Gorman <mgorman@suse.de>
      Link: http://lkml.kernel.org/r/1429894848.10273.44.camel@stgolabs.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      052b0f6e
    • H
      perf probe: Fix bug with global variables handling · d13855ef
      He Kuang 提交于
      There are missing curly braces which causes find_variable() return wrong
      value when probing with global variables.
      
      This problem can be reproduced as following:
      
        $ perf probe -v --add='generic_perform_write global_variable_for_test'
        ...
        Try to find probe point from debuginfo.
        Probe point found: generic_perform_write+0
        Searching 'global_variable_for_test' variable in context.
        An error occurred in debuginfo analysis (-2).
          Error: Failed to add events. Reason: No such file or directory (Code: -2)
      
      After this patch:
      
        $ perf probe -v --add='generic_perform_write global_variable_for_test'
        ...
        Converting variable global_variable_for_test into trace event.
        global_variable_for_test type is int.
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Added new event:
        Writing event: p:probe/generic_perform_write _stext+1237464
        global_variable_for_test=@global_variable_for_test+0:s32
          probe:generic_perform_write (on generic_perform_write with
          global_variable_for_test)
      
        You can now use it in all perf tools, such as:
      
            perf record -e probe:generic_perform_write -aR sleep 1
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.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/1429949338-18678-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d13855ef
    • W
      perf top: Fix a segfault when kernel map is restricted. · c6718350
      Wang Nan 提交于
      Perf top raise a warning if a kernel sample is collected but kernel map
      is restricted. The warning message needs to dereference al.map->dso...
      
      However, previous perf_event__preprocess_sample() doesn't always
      guarantee al.map != NULL, for example, when kernel map is restricted.
      
      This patch validates al.map before dereferencing, avoid the segfault.
      
      Before this patch:
      
       $ cat /proc/sys/kernel/kptr_restrict
       1
       $ perf top -p  120183
       perf: Segmentation fault
       -------- backtrace --------
       /path/to/perf[0x509868]
       /lib64/libc.so.6(+0x3545f)[0x7f9a1540045f]
       /path/to/perf[0x448820]
       /path/to/perf(cmd_top+0xe3c)[0x44a5dc]
       /path/to/perf[0x4766a2]
       /path/to/perf(main+0x5f5)[0x42e545]
       /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f9a153ecbd4]
       /path/to/perf[0x42e674]
      
      And gdb call trace:
      
       Program received signal SIGSEGV, Segmentation fault.
       perf_event__process_sample (machine=0xa44030, sample=0x7fffffffa4c0, evsel=0xa43b00, event=0x7ffff41c3000, tool=0x7fffffffa8a0)
          at builtin-top.c:736
       736				  !RB_EMPTY_ROOT(&al.map->dso->symbols[MAP__FUNCTION]) ?
       (gdb) bt
       #0  perf_event__process_sample (machine=0xa44030, sample=0x7fffffffa4c0, evsel=0xa43b00, event=0x7ffff41c3000, tool=0x7fffffffa8a0)
           at builtin-top.c:736
       #1  perf_top__mmap_read_idx (top=top@entry=0x7fffffffa8a0, idx=idx@entry=0) at builtin-top.c:855
       #2  0x000000000044a5dd in perf_top__mmap_read (top=0x7fffffffa8a0) at builtin-top.c:872
       #3  __cmd_top (top=0x7fffffffa8a0) at builtin-top.c:997
       #4  cmd_top (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin-top.c:1267
       #5  0x00000000004766a3 in run_builtin (p=p@entry=0x8a6ce8 <commands+264>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdf70)
            at perf.c:371
       #6  0x000000000042e546 in handle_internal_command (argv=0x7fffffffdf70, argc=3) at perf.c:430
       #7  run_argv (argv=0x7fffffffdcf0, argcp=0x7fffffffdcfc) at perf.c:474
       #8  main (argc=3, argv=0x7fffffffdf70) at perf.c:589
       (gdb)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Link: http://lkml.kernel.org/r/1429946703-80807-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c6718350
  9. 24 4月, 2015 6 次提交
    • N
      tools lib traceevent: Fix build failure on 32-bit arch · 410ceb8f
      Namhyung Kim 提交于
      In my i386 build, it failed like this:
      
          CC       event-parse.o
        event-parse.c: In function 'print_str_arg':
        event-parse.c:3868:5: warning: format '%lu' expects argument of type 'long unsigned int',
                              but argument 3 has type 'uint64_t' [-Wformat]
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NJavi Merino <javi.merino@arm.com>
      Link: http://lkml.kernel.org/r/20150424020218.GF1905@sejongSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      410ceb8f
    • D
      perf kmem: Fix compiles on RHEL6/OL6 · 4ad1f430
      David Ahern 提交于
      0d68bc92 breaks compiles on RHEL6/OL6:
          cc1: warnings being treated as errors
          builtin-kmem.c: In function ‘search_page_alloc_stat’:
          builtin-kmem.c:322: error: declaration of ‘stat’ shadows a global declaration
                                  node = &parent->rb_left;
          /usr/include/sys/stat.h:455: error: shadowed declaration is here
          builtin-kmem.c: In function ‘perf_evsel__process_page_alloc_event’:
          builtin-kmem.c:378: error: declaration of ‘stat’ shadows a global declaration
          /usr/include/sys/stat.h:455: error: shadowed declaration is here
          builtin-kmem.c: In function ‘perf_evsel__process_page_free_event’:
          builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global declaration
          /usr/include/sys/stat.h:455: error: shadowed declaration is here
      
      Rename local variable to pstat to avoid the name conflict.
      Signed-off-by: NDavid Ahern <david.ahern@oracle.com>
      Link: http://lkml.kernel.org/r/1429033773-31383-1-git-send-email-david.ahern@oracle.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4ad1f430
    • B
      tools lib api: Undefine _FORTIFY_SOURCE before setting it · de28c15d
      Bobby Powers 提交于
      Some toolchains (like Hardened Gentoo) define _FORTIFY_SOURCE in the
      built-in, default args.  This causes perf builds to fail with:
      
      <command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
      <built-in>: note: this is the location of the previous definition cc1:
      all warnings being treated as errors
      
      To avoid this, undefine _FORTIFY_SOURCE before (possibly re-)defining it
      in tools/lib/api.
      
      v2 applies cleanly on top of already pulled kbuild changes for 4.1-rc1.
      Signed-off-by: NBobby Powers <bobbypowers@gmail.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Dirk Gouders <dirk@gouders.net>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linux-kbuild@vger.kernel.org
      Link: http://lkml.kernel.org/r/1429658381-3039-1-git-send-email-bobbypowers@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      de28c15d
    • W
      perf kmem: Consistently use PRIu64 for printing u64 values · 6145c259
      Will Deacon 提交于
      Building the perf tool for 32-bit ARM results in the following build
      error due to a combination of an incorrect conversion specifier and
      compiling with -Werror:
      
        builtin-kmem.c: In function ‘print_page_summary’:
        builtin-kmem.c:644:9: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘u64’ [-Werror=format=]
                 nr_alloc_freed, (total_alloc_freed_bytes) / 1024);
                 ^
        builtin-kmem.c:647:9: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘u64’ [-Werror=format=]
                 (total_page_alloc_bytes - total_alloc_freed_bytes) / 1024);
                 ^
        cc1: all warnings being treated as errors
      
      This patch fixes the problem by consistently using PRIu64 for printing
      out u64 values.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      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: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1429796437-1790-1-git-send-email-will.deacon@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6145c259
    • A
      perf trace: Disable events and drain events when forked workload ends · 02ac5421
      Arnaldo Carvalho de Melo 提交于
      We were not checking in the inner event processing loop if the forked workload
      had finished, which, on a busy system, may make it take a long time trying to
      drain events, entering a seemingly neverending loop, waiting for the system to
      get idle enough to make it drain the buffers.
      
      Fix it by disabling the events when 'done' is true, in the inner loop, to start
      draining what is in the buffers.
      
      Now:
      
      [root@ssdandy ~]# time trace --filter-pids 14003 -a sleep 1 | tail
        996.748 ( 0.002 ms): sh/30296 rt_sigprocmask(how: SETMASK, nset: 0x7ffc83418160, sigsetsize: 8) = 0
        996.751 ( 0.002 ms): sh/30296 rt_sigprocmask(how: BLOCK, nset: 0x7ffc834181f0, oset: 0x7ffc83418270, sigsetsize: 8) = 0
        996.755 ( 0.002 ms): sh/30296 rt_sigaction(sig: INT, act: 0x7ffc83417f50, oact: 0x7ffc83417ff0, sigsetsize: 8) = 0
       1004.543 ( 0.362 ms): tail/30198  ... [continued]: read()) = 4096
       1004.548 ( 7.791 ms): sh/30296 wait4(upid: -1, stat_addr: 0x7ffc834181a0) ...
       1004.975 ( 0.427 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
       1005.390 ( 0.410 ms): tail/30198 read(buf: 0x765410, count: 8192) = 4096
       1005.743 ( 0.348 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
       1006.197 ( 0.449 ms): tail/30198 read(buf: 0x765410, count: 8192) = 4096
       1006.492 ( 0.290 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
      
      real	0m1.219s
      user	0m0.704s
      sys	0m0.331s
      [root@ssdandy ~]#
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Suggested-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      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: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-p6kpn1b26qcbe47pufpw0tex@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      02ac5421
    • A
      perf trace: Enable events when doing system wide tracing and starting a workload · cb24d01d
      Arnaldo Carvalho de Melo 提交于
       commit f7aa222f
       Author: Arnaldo Carvalho de Melo <acme@redhat.com>
       Date:   Tue Feb 3 13:25:39 2015 -0300
      
          perf trace: No need to enable evsels for workload started from perf
      
      The assumption was that whenever a workload is specified, the
      attr.enable_on_exec evsel flag would be set, but that is not happening
      when perf_record_opts.system_wide is set, for instance
      
      That resulted in both perf_evlist__enable() and attr.enable_on_exec
      being not called/set, which made the events to remain disabled while the
      workload runs, producing no output.
      
      Fix it,  by calling perf_evlist__enable() in the 'trace' tool
      when forking and not targetting a workload started from trace
      
      v2: Test against !target__none(), as suggested by Namhyung Kim, that is
      what is used in perf_evsel__config() when deciding if the
      attr.enable_on_exec flag to be set. More work is needed to cover other
      cases such as opts->initial_delay.
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      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: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-27z7169pvfxgj8upic636syv@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cb24d01d
  10. 19 4月, 2015 8 次提交
  11. 16 4月, 2015 3 次提交
  12. 14 4月, 2015 1 次提交