1. 09 Sep, 2010 3 commits
  2. 08 Sep, 2010 6 commits
    • Masami Hiramatsu's avatar
      tracing/kprobe: Fix handling of C-unlike argument names · da34634f
      Masami Hiramatsu authored
      Check the argument name whether it is invalid (not C-like symbol name). This
      makes event format simple.
      Reported-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      LKML-Reference: <20100827113912.22882.62313.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      da34634f
    • Masami Hiramatsu's avatar
      tracing/kprobes: Fix handling of argument names · aba91595
      Masami Hiramatsu authored
      Set "argN" name for each argument automatically if it has no specified name.
      Since dynamic trace event(kprobe_events) accepts special characters for its
      argument, its format can show those special characters (e.g. '$', '%', '+').
      However, perf can't parse those format because of the character (especially
      '%') mess up the format.  This sets "argX" name for those arguments if user
      omitted the argument names.
      
      E.g.
       # echo 'p do_fork %ax IP=%ip $stack' > tracing/kprobe_events
       # cat tracing/kprobe_events
       p:kprobes/p_do_fork_0 do_fork arg1=%ax IP=%ip arg3=$stack
      Reported-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      LKML-Reference: <20100827113906.22882.59312.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      aba91595
    • Masami Hiramatsu's avatar
      perf probe: Fix handling of arguments names · 367e94c1
      Masami Hiramatsu authored
      Don't make argument names from raw parameters (means the parameters are written
      in kprobe-tracer syntax), because the argument syntax may include special
      characters.  Just leave it, then kprobe-tracer gives a new name.
      Reported-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20100827113859.22882.75598.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      367e94c1
    • Masami Hiramatsu's avatar
      perf probe: Fix return probe support · 04ddd04b
      Masami Hiramatsu authored
      Fix a bug to support %return probe syntax again. Previous commit 4235b045 has a
      bug which disables the %return syntax on perf probe.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20100827113852.22882.87447.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      04ddd04b
    • Masami Hiramatsu's avatar
      tracing/kprobe: Fix a memory leak in error case · 61a52736
      Masami Hiramatsu authored
      Fix a memory leak which happens when a field name conflicts with others. In
      error case, free_trace_probe() will free all arguments until nr_args, so this
      increments nr_args the begining of the loop instead of the end.
      
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      LKML-Reference: <20100827113846.22882.12670.stgit@ltc236.sdl.hitachi.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      61a52736
    • Steven Rostedt's avatar
      tracing: Do not allow llseek to set_ftrace_filter · 9c55cb12
      Steven Rostedt authored
      Reading the file set_ftrace_filter does three things.
      
      1) shows whether or not filters are set for the function tracer
      2) shows what functions are set for the function tracer
      3) shows what triggers are set on any functions
      
      3 is independent from 1 and 2.
      
      The way this file currently works is that it is a state machine,
      and as you read it, it may change state. But this assumption breaks
      when you use lseek() on the file. The state machine gets out of sync
      and the t_show() may use the wrong pointer and cause a kernel oops.
      
      Luckily, this will only kill the app that does the lseek, but the app
      dies while holding a mutex. This prevents anyone else from using the
      set_ftrace_filter file (or any other function tracing file for that matter).
      
      A real fix for this is to rewrite the code, but that is too much for
      a -rc release or stable. This patch simply disables llseek on the
      set_ftrace_filter() file for now, and we can do the proper fix for the
      next major release.
      Reported-by: default avatarRobert Swiecki <swiecki@google.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Tavis Ormandy <taviso@google.com>
      Cc: Eugene Teo <eugene@redhat.com>
      Cc: vendor-sec@lst.de
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      9c55cb12
  3. 07 Sep, 2010 5 commits
    • Koki Sanagi's avatar
      perf: Add a script to show packets processing · 359d5106
      Koki Sanagi authored
      Add a perf script which shows packets processing and processed
      time. It helps us to investigate networking or network devices.
      
      If you want to use it, install perf and record perf.data like
      following.
      
      If you set script, perf gathers records until it ends.
      If not, you must Ctrl-C to stop recording.
      
      And if you want a report from record,
      
      If you use some options, you can limit the output.
      Option is below.
      
      tx: show only tx packets processing
      rx: show only rx packets processing
      dev=: show processing on this device
      debug: work with debug mode. It shows buffer status.
      
      For example, if you want to show received packets processing
      associated with eth4,
      
      106133.171439sec cpu=0
        irq_entry(+0.000msec irq=24:eth4)
               |
        softirq_entry(+0.006msec)
               |
               |---netif_receive_skb(+0.010msec skb=f2d15900 len=100)
               |            |
               |      skb_copy_datagram_iovec(+0.039msec 10291::10291)
               |
        napi_poll_exit(+0.022msec eth4)
      
      This perf script helps us to analyze the processing time of a
      transmit/receive sequence.
      Signed-off-by: default avatarKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Kaneshige Kenji <kaneshige.kenji@jp.fujitsu.com>
      Cc: Izumo Taku <izumi.taku@jp.fujitsu.com>
      Cc: Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Scott Mcmillan <scott.a.mcmillan@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <4C72439D.3040001@jp.fujitsu.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      359d5106
    • Koki Sanagi's avatar
      skb: Add tracepoints to freeing skb · 07dc22e7
      Koki Sanagi authored
      This patch adds tracepoint to consume_skb and add trace_kfree_skb
      before __kfree_skb in skb_free_datagram_locked and net_tx_action.
      Combinating with tracepoint on dev_hard_start_xmit, we can check
      how long it takes to free transmitted packets. And using it, we can
      calculate how many packets driver had at that time. It is useful when
      a drop of transmitted packet is a problem.
      
                  sshd-6828  [000] 112689.258154: consume_skb: skbaddr=f2d99bb8
      Signed-off-by: default avatarKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Kaneshige Kenji <kaneshige.kenji@jp.fujitsu.com>
      Cc: Izumo Taku <izumi.taku@jp.fujitsu.com>
      Cc: Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Scott Mcmillan <scott.a.mcmillan@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      LKML-Reference: <4C724364.50903@jp.fujitsu.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      07dc22e7
    • Koki Sanagi's avatar
      netdev: Add tracepoints to netdev layer · cf66ba58
      Koki Sanagi authored
      This patch adds tracepoint to dev_queue_xmit, dev_hard_start_xmit,
      netif_rx and netif_receive_skb. These tracepoints help you to monitor
      network driver's input/output.
      
                <idle>-0     [001] 112447.902030: netif_rx: dev=eth1 skbaddr=f3ef0900 len=84
                <idle>-0     [001] 112447.902039: netif_receive_skb: dev=eth1 skbaddr=f3ef0900 len=84
                  sshd-6828  [000] 112447.903257: net_dev_queue: dev=eth4 skbaddr=f3fca538 len=226
                  sshd-6828  [000] 112447.903260: net_dev_xmit: dev=eth4 skbaddr=f3fca538 len=226 rc=0
      Signed-off-by: default avatarKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Kaneshige Kenji <kaneshige.kenji@jp.fujitsu.com>
      Cc: Izumo Taku <izumi.taku@jp.fujitsu.com>
      Cc: Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Scott Mcmillan <scott.a.mcmillan@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      LKML-Reference: <4C72431E.3000901@jp.fujitsu.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      cf66ba58
    • Neil Horman's avatar
      napi: Convert trace_napi_poll to TRACE_EVENT · 3e4b10d7
      Neil Horman authored
      This patch converts trace_napi_poll from DECLARE_EVENT to TRACE_EVENT
      to improve the usability of napi_poll tracepoint.
      
                <idle>-0     [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3
                <idle>-0     [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1
      
      The original patch is below:
      http://marc.info/?l=linux-kernel&m=126021713809450&w=2
      
      [ sanagi.koki@jp.fujitsu.com: And add a fix by Steven Rostedt:
      http://marc.info/?l=linux-kernel&m=126150506519173&w=2 ]
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Kaneshige Kenji <kaneshige.kenji@jp.fujitsu.com>
      Cc: Izumo Taku <izumi.taku@jp.fujitsu.com>
      Cc: Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Scott Mcmillan <scott.a.mcmillan@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      LKML-Reference: <4C7242D7.4050009@jp.fujitsu.com>
      Signed-off-by: default avatarKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      3e4b10d7
    • Lai Jiangshan's avatar
      irq: Add tracepoint to softirq_raise · 2bf2160d
      Lai Jiangshan authored
      Add a tracepoint for tracing when softirq action is raised.
      
      This and the existing tracepoints complete softirq's tracepoints:
      softirq_raise, softirq_entry and softirq_exit.
      
      And when this tracepoint is used in combination with
      the softirq_entry tracepoint we can determine
      the softirq raise latency.
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Kaneshige Kenji <kaneshige.kenji@jp.fujitsu.com>
      Cc: Izumo Taku <izumi.taku@jp.fujitsu.com>
      Cc: Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Scott Mcmillan <scott.a.mcmillan@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      LKML-Reference: <4C724298.4050509@jp.fujitsu.com>
      [ factorize softirq events with DECLARE_EVENT_CLASS ]
      Signed-off-by: default avatarKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      2bf2160d
  4. 03 Sep, 2010 3 commits
    • Robert Richter's avatar
      perf, x86: Try to handle unknown nmis with an enabled PMU · 4177c42a
      Robert Richter authored
      When the PMU is enabled it is valid to have unhandled nmis, two
      events could trigger 'simultaneously' raising two back-to-back
      NMIs. If the first NMI handles both, the latter will be empty
      and daze the CPU.
      
      The solution to avoid an 'unknown nmi' massage in this case was
      simply to stop the nmi handler chain when the PMU is enabled by
      stating the nmi was handled. This has the drawback that a) we
      can not detect unknown nmis anymore, and b) subsequent nmi
      handlers are not called.
      
      This patch addresses this. Now, we check this unknown NMI if it
      could be a PMU back-to-back NMI. Otherwise we pass it and let
      the kernel handle the unknown nmi.
      
      This is a debug log:
      
       cpu #6, nmi #32333, skip_nmi #32330, handled = 1, time = 1934364430
       cpu #6, nmi #32334, skip_nmi #32330, handled = 1, time = 1934704616
       cpu #6, nmi #32335, skip_nmi #32336, handled = 2, time = 1936032320
       cpu #6, nmi #32336, skip_nmi #32336, handled = 0, time = 1936034139
       cpu #6, nmi #32337, skip_nmi #32336, handled = 1, time = 1936120100
       cpu #6, nmi #32338, skip_nmi #32336, handled = 1, time = 1936404607
       cpu #6, nmi #32339, skip_nmi #32336, handled = 1, time = 1937983416
       cpu #6, nmi #32340, skip_nmi #32341, handled = 2, time = 1938201032
       cpu #6, nmi #32341, skip_nmi #32341, handled = 0, time = 1938202830
       cpu #6, nmi #32342, skip_nmi #32341, handled = 1, time = 1938443743
       cpu #6, nmi #32343, skip_nmi #32341, handled = 1, time = 1939956552
       cpu #6, nmi #32344, skip_nmi #32341, handled = 1, time = 1940073224
       cpu #6, nmi #32345, skip_nmi #32341, handled = 1, time = 1940485677
       cpu #6, nmi #32346, skip_nmi #32347, handled = 2, time = 1941947772
       cpu #6, nmi #32347, skip_nmi #32347, handled = 1, time = 1941949818
       cpu #6, nmi #32348, skip_nmi #32347, handled = 0, time = 1941951591
       Uhhuh. NMI received for unknown reason 00 on CPU 6.
       Do you have a strange power saving mode enabled?
       Dazed and confused, but trying to continue
      
      Deltas:
      
       nmi #32334 340186
       nmi #32335 1327704
       nmi #32336 1819      <<<< back-to-back nmi [1]
       nmi #32337 85961
       nmi #32338 284507
       nmi #32339 1578809
       nmi #32340 217616
       nmi #32341 1798      <<<< back-to-back nmi [2]
       nmi #32342 240913
       nmi #32343 1512809
       nmi #32344 116672
       nmi #32345 412453
       nmi #32346 1462095   <<<< 1st nmi (standard) handling 2 counters
       nmi #32347 2046      <<<< 2nd nmi (back-to-back) handling one
       counter nmi #32348 1773      <<<< 3rd nmi (back-to-back)
       handling no counter! [3]
      
      For  back-to-back nmi detection there are the following rules:
      
      The PMU nmi handler was handling more than one counter and no
      counter was handled in the subsequent nmi (see [1] and [2]
      above).
      
      There is another case if there are two subsequent back-to-back
      nmis [3]. The 2nd is detected as back-to-back because the first
      handled more than one counter. If the second handles one counter
      and the 3rd handles nothing, we drop the 3rd nmi because it
      could be a back-to-back nmi.
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      [ renamed nmi variable to pmu_nmi to avoid clash with .nmi in entry.S ]
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-3-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4177c42a
    • Peter Zijlstra's avatar
      perf, x86: Fix handle_irq return values · de725dec
      Peter Zijlstra authored
      Now that we rely on the number of handled overflows, ensure all
      handle_irq implementations actually return the right number.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: robert.richter@amd.com
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      de725dec
    • Don Zickus's avatar
      perf, x86: Fix accidentally ack'ing a second event on intel perf counter · 2e556b5b
      Don Zickus authored
      During testing of a patch to stop having the perf subsytem
      swallow nmis, it was uncovered that Nehalem boxes were randomly
      getting unknown nmis when using the perf tool.
      
      Moving the ack'ing of the PMI closer to when we get the status
      allows the hardware to properly re-set the PMU bit signaling
      another PMI was triggered during the processing of the first
      PMI.  This allows the new logic for dealing with the
      shortcomings of multiple PMIs to handle the extra NMI by
      'eat'ing it later.
      
      Now one can wonder why are we getting a second PMI when we
      disable all the PMUs in the begining of the NMI handler to
      prevent such a case, for that I do not know.  But I know the fix
      below helps deal with this quirk.
      
      Tested on multiple Nehalems where the problem was occuring.
      With the patch, the code now loops a second time to handle the
      second PMI (whereas before it was not).
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: robert.richter@amd.com
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2e556b5b
  5. 01 Sep, 2010 7 commits
  6. 31 Aug, 2010 3 commits
    • Li Zefan's avatar
      tracing: Fix a race in function profile · 3aaba20f
      Li Zefan authored
      While we are reading trace_stat/functionX and someone just
      disabled function_profile at that time, we can trigger this:
      
      	divide error: 0000 [#1] PREEMPT SMP
      	...
      	EIP is at function_stat_show+0x90/0x230
      	...
      
      This fix just takes the ftrace_profile_lock and checks if
      rec->counter is 0. If it's 0, we know the profile buffer
      has been reset.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Cc: stable@kernel.org
      LKML-Reference: <4C723644.4040708@cn.fujitsu.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      3aaba20f
    • Steven Rostedt's avatar
      tracing/lockdep: Fix dependency of TRACE_IRQFLAGS · 46b93b74
      Steven Rostedt authored
      When CONFIG_IRQSOFF_TRACER is set and CONFIG_PROVE_LOCKING is not, we
      get the following error:
      
      $  make oldconfig
      scripts/kconfig/conf --oldconfig arch/x86/Kconfig
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      
      This is because IRQSOFF_TRACER selects TRACE_IRQFLAGS but TRACE_IRQFLAGS
      has PROVE_LOCKING as a dependency. This code is incorrect, and
      this patch changes the TRACE_IRQFLAGS to be just a simple bool that
      does not depend or select anything. Instead both IRQSOFF_TRACER and
      PROVE_LOCKING select it.
      Reported-by: default avatarRichard Kennedy <richard@rsk.demon.co.uk>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      46b93b74
    • Robert Richter's avatar
      oprofile, x86: fix init_sysfs error handling · 10f0412f
      Robert Richter authored
      On failure init_sysfs() might not properly free resources. The error
      code of the function is not checked. And, when reinitializing the exit
      function might be called twice. This patch fixes all this.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      10f0412f
  7. 30 Aug, 2010 2 commits
    • Stephane Eranian's avatar
      perf_events: Fix time tracking for events with pid != -1 and cpu != -1 · fa66f07a
      Stephane Eranian authored
      Per-thread events with a cpu filter, i.e., cpu != -1, were not
      reporting correct timings when the thread never ran on the
      monitored cpu. The time enabled was reported as a negative
      value.
      
      This patch fixes the problem by updating tstamp_stopped,
      tstamp_running in event_sched_out() for events with filters and
      which are marked as INACTIVE.
      
      The function group_sched_out() is modified to systematically
      call into event_sched_out() to avoid duplicating the timing
      adjustment code twice.
      
      With the patch, I now get:
      
      $ task_cpu -i -e unhalted_core_cycles,unhalted_core_cycles
      noploop 2 noploop for 2 seconds
      CPU0 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      CPU0 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      
      CPU1 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      CPU1 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      
      CPU2 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      CPU2 0		   unhalted_core_cycles (ena=1,991,136,594, run=0)
      
      CPU3 4,747,990,931 unhalted_core_cycles (ena=1,991,136,594, run=1,991,136,594)
      CPU3 4,747,990,931 unhalted_core_cycles (ena=1,991,136,594, run=1,991,136,594)
      Signed-off-by: default avatarStephane Eranian <eranian@gmail.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus@samba.org
      Cc: davem@davemloft.net
      Cc: fweisbec@gmail.com
      Cc: perfmon2-devel@lists.sf.net
      Cc: eranian@google.com
      LKML-Reference: <4c76802d.aae9d80a.115d.70fe@mx.google.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fa66f07a
    • Ingo Molnar's avatar
      Merge branch 'perf/core' of... · 3449dafa
      Ingo Molnar authored
      Merge branch 'perf/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into perf/core
      3449dafa
  8. 27 Aug, 2010 1 commit
  9. 26 Aug, 2010 1 commit
    • Frederic Weisbecker's avatar
      perf: Initialize callchains roots's childen hits · 5225c458
      Frederic Weisbecker authored
      Each histogram entry has a callchain root that stores the
      callchain samples. However we forgot to initialize the
      tracking of children hits of these roots, which then got
      random values on their creation.
      
      The root children hits is multiplied by the minimum percentage
      of hits provided by the user, and the result becomes the minimum
      hits expected from children branches. If the random value due
      to the uninitialization is big enough, then this minimum number
      of hits can be huge and eventually filter every children branches.
      
      The end result was invisible callchains. All we need to
      fix this is to initialize the children hits of the root.
      Reported-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: 2.6.32.x-2.6.35.y <stable@kernel.org>
      5225c458
  10. 25 Aug, 2010 9 commits