1. 24 3月, 2011 2 次提交
    • A
      perf session: Pass evsel in event_ops->sample() · 9e69c210
      Arnaldo Carvalho de Melo 提交于
      Resolving the sample->id to an evsel since the most advanced tools,
      report and annotate, and the others will too when they evolve to
      properly support multi-event perf.data files.
      
      Good also because it does an extra validation, checking that the ID is
      valid when present. When that is not the case, the overhead is just a
      branch + function call (perf_evlist__id2evsel).
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9e69c210
    • F
      perf: Better fit max unprivileged mlock pages for tools needs · 880f5731
      Frederic Weisbecker 提交于
      The maximum kilobytes of locked memory that an unprivileged user
      can reserve is of 512 kB = 128 pages by default, scaled to the
      number of onlined CPUs, which fits well with the tools that use
      128 data pages by default.
      
      However tools actually use 129 pages, because they need one more
      for the user control page. Thus the default mlock threshold is
      not sufficient for the default tools needs and we always end up
      to evaluate the constant mlock rlimit policy, which doesn't have
      this scaling with the number of online CPUs.
      
      Hence, on systems that have more than 16 CPUs, we overlap the
      rlimit threshold and fail to mmap:
      
      	$ perf record ls
      	Error: failed to mmap with 1 (Operation not permitted)
      
      Just increase the max unprivileged mlock threshold by one page
      so that it supports well perf tools even after 16 CPUs.
      Reported-by: NHan Pingtian <phan@redhat.com>
      Reported-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Stable <stable@kernel.org>
      LKML-Reference: <1300904979-5508-1-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      880f5731
  2. 23 3月, 2011 4 次提交
    • S
      perf_events: Fix stale ->cgrp pointer in update_cgrp_time_from_cpuctx() · 68cacd29
      Stephane Eranian 提交于
      This patch solves a stale pointer problem in
      update_cgrp_time_from_cpuctx(). The cpuctx->cgrp
      was not cleared on all possible event exit paths,
      including:
      
         close()
           perf_release()
             perf_release_kernel()
               list_del_event()
      
      This patch fixes list_del_event() to clear cpuctx->cgrp
      when there are no cgroup events left in the context.
      
      [ This second version makes the code compile when
        CONFIG_CGROUP_PERF is not enabled. We unconditionally define
        perf_cpu_context->cgrp. ]
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: peterz@infradead.org
      Cc: perfmon2-devel@lists.sf.net
      Cc: paulus@samba.org
      Cc: davem@davemloft.net
      LKML-Reference: <20110323150306.GA1580@quad>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      68cacd29
    • A
      perf top: Fix uninitialized 'counter' variable · ce2d17ca
      Akihiro Nagai 提交于
      builtin-top.c has an uninitialized variable.
      gcc(version 4.5.1) warns about it and it results in build failure:
      
       builtin-top.c: In function 'display_thread':
       builtin-top.c:518:9: error: 'counter' may be used uninitialized
      
      This situation can indeed trigger, if the getline() call in
      prompt_integer() fails.
      Signed-off-by: NAkihiro Nagai <akihiro.nagai.hw@hitachi.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110323072939.11638.50173.stgit@localhost6.localdomain6>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce2d17ca
    • I
      Merge branch 'tip/perf/urgent' of... · e1eb0290
      Ingo Molnar 提交于
      Merge branch 'tip/perf/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace into perf/urgent
      e1eb0290
    • J
      tracing: Fix set_ftrace_filter probe function display · 1106b699
      Jiri Olsa 提交于
      If one or more function probes (like traceon) are enabled,
      and there's no other function filter, the first probe
      func is skipped (which one depends on the position in the hash).
      
      $ echo sys_open:traceon sys_close:traceon > ./set_ftrace_filter
      $ cat set_ftrace_filter
      #### all functions enabled ####
      sys_close:traceon:unlimited
      $
      
      The reason was, that in the case of no other function filter,
      the func_pos was not properly updated before calling t_hash_start.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      LKML-Reference: <1297874134-7008-1-git-send-email-jolsa@redhat.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      1106b699
  3. 20 3月, 2011 1 次提交
    • S
      perf, x86: Fix Intel fixed counters base initialization · fc66c521
      Stephane Eranian 提交于
      The following patch solves the problems introduced by Robert's
      commit 41bf4989 and reported by Arun Sharma. This commit gets rid
      of the base + index notation for reading and writing PMU msrs.
      
      The problem is that for fixed counters, the new calculation for
      the base did not take into account the fixed counter indexes,
      thus all fixed counters were read/written from fixed counter 0.
      Although all fixed counters share the same config MSR, they each
      have their own counter register.
      
      Without:
      
       $ task -e unhalted_core_cycles -e instructions_retired -e baclears noploop 1 noploop for 1 seconds
      
        242202299 unhalted_core_cycles (0.00% scaling, ena=1000790892, run=1000790892)
       2389685946 instructions_retired (0.00% scaling, ena=1000790892, run=1000790892)
            49473 baclears             (0.00% scaling, ena=1000790892, run=1000790892)
      
      With:
      
       $ task -e unhalted_core_cycles -e instructions_retired -e baclears noploop 1 noploop for 1 seconds
      
       2392703238 unhalted_core_cycles (0.00% scaling, ena=1000840809, run=1000840809)
       2389793744 instructions_retired (0.00% scaling, ena=1000840809, run=1000840809)
            47863 baclears             (0.00% scaling, ena=1000840809, run=1000840809)
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: peterz@infradead.org
      Cc: ming.m.lin@intel.com
      Cc: robert.richter@amd.com
      Cc: asharma@fb.com
      Cc: perfmon2-devel@lists.sf.net
      LKML-Reference: <20110319172005.GB4978@quad>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc66c521
  4. 18 3月, 2011 1 次提交
  5. 17 3月, 2011 3 次提交
  6. 16 3月, 2011 29 次提交