1. 10 9月, 2010 7 次提交
    • P
      perf: Reduce perf_disable() usage · 24cd7f54
      Peter Zijlstra 提交于
      Since the current perf_disable() usage is only an optimization,
      remove it for now. This eases the removal of the __weak
      hw_perf_enable() interface.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Michael Cree <mcree@orcon.net.nz>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      24cd7f54
    • P
      perf: Unindent labels · 9ed6060d
      Peter Zijlstra 提交于
      Fixup random annoying style bits.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus <paulus@samba.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9ed6060d
    • P
      perf: Register PMU implementations · b0a873eb
      Peter Zijlstra 提交于
      Simple registration interface for struct pmu, this provides the
      infrastructure for removing all the weak functions.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Michael Cree <mcree@orcon.net.nz>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b0a873eb
    • P
      perf: Deconstify struct pmu · 51b0fe39
      Peter Zijlstra 提交于
      sed -ie 's/const struct pmu\>/struct pmu/g' `git grep -l "const struct pmu\>"`
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Michael Cree <mcree@orcon.net.nz>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      51b0fe39
    • I
      Merge branch 'perf/urgent' into perf/core · 2aa61274
      Ingo Molnar 提交于
      Merge reason: Pick up pending fixes before applying dependent new changes.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2aa61274
    • P
      perf: Fix CPU hotplug · 5e11637e
      Peter Zijlstra 提交于
      Since we have UP_PREPARE, we should also have UP_CANCELED.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: paulus <paulus@samba.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5e11637e
    • L
      perf, trace: Fix module leak · 9cb627d5
      Li Zefan 提交于
      Commit 1c024eca (perf, trace: Optimize tracepoints by using
      per-tracepoint-per-cpu hlist to track events) caused a module
      refcount leak.
      Reported-And-Tested-by: NAvi Kivity <avi@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <4C7E1F12.8030304@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9cb627d5
  2. 08 9月, 2010 5 次提交
  3. 09 9月, 2010 1 次提交
    • S
      tracing: Do not allow llseek to set_ftrace_filter · 9c55cb12
      Steven Rostedt 提交于
      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: NRobert 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: NSteven Rostedt <rostedt@goodmis.org>
      9c55cb12
  4. 08 9月, 2010 1 次提交
    • K
      perf: Add a script to show packets processing · 359d5106
      Koki Sanagi 提交于
      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: NKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: NDavid 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: NFrederic Weisbecker <fweisbec@gmail.com>
      359d5106
  5. 07 9月, 2010 4 次提交
    • K
      skb: Add tracepoints to freeing skb · 07dc22e7
      Koki Sanagi 提交于
      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: NKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NNeil 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: NFrederic Weisbecker <fweisbec@gmail.com>
      07dc22e7
    • K
      netdev: Add tracepoints to netdev layer · cf66ba58
      Koki Sanagi 提交于
      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: NKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NNeil 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: NFrederic Weisbecker <fweisbec@gmail.com>
      cf66ba58
    • N
      napi: Convert trace_napi_poll to TRACE_EVENT · 3e4b10d7
      Neil Horman 提交于
      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: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NNeil 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: NKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      3e4b10d7
    • L
      irq: Add tracepoint to softirq_raise · 2bf2160d
      Lai Jiangshan 提交于
      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: NLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NNeil 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: NKoki Sanagi <sanagi.koki@jp.fujitsu.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      2bf2160d
  6. 03 9月, 2010 3 次提交
    • R
      perf, x86: Try to handle unknown nmis with an enabled PMU · 4177c42a
      Robert Richter 提交于
      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: NRobert Richter <robert.richter@amd.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      [ renamed nmi variable to pmu_nmi to avoid clash with .nmi in entry.S ]
      Signed-off-by: NDon 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: NIngo Molnar <mingo@elte.hu>
      4177c42a
    • P
      perf, x86: Fix handle_irq return values · de725dec
      Peter Zijlstra 提交于
      Now that we rely on the number of handled overflows, ensure all
      handle_irq implementations actually return the right number.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NDon 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: NIngo Molnar <mingo@elte.hu>
      de725dec
    • D
      perf, x86: Fix accidentally ack'ing a second event on intel perf counter · 2e556b5b
      Don Zickus 提交于
      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: NDon 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: NIngo Molnar <mingo@elte.hu>
      2e556b5b
  7. 02 9月, 2010 3 次提交
    • I
      Merge branch 'urgent' of... · b4c69d45
      Ingo Molnar 提交于
      Merge branch 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile into perf/urgent
      b4c69d45
    • R
      oprofile, x86: fix init_sysfs() function stub · 269f45c2
      Robert Richter 提交于
      The use of the return value of init_sysfs() with commit
      
       10f0412f oprofile, x86: fix init_sysfs error handling
      
      discovered the following build error for !CONFIG_PM:
      
       .../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’:
       .../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’
       make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1
       make[1]: *** [arch/x86/oprofile] Error 2
      
      This patch fixes this.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      269f45c2
    • S
      ring-buffer: Place duplicate expression into a single function · f6195aa0
      Steven Rostedt 提交于
      While discussing the strictness of the 80 character limit on the
      Kernel Summit Discussion mailing list, I showed examples that I
      broke that limit slightly with some algorithms. In discussing with
      John Linville, what looked better, I realized that two of the
      80 char breaking culprits were an identical expression.
      
      As a clean up, this patch moves the identical expression into its
      own helper function and that is used instead. As a side effect,
      the offending code is now under the 80 character limit. :-)
      
      This clean up code also changes the expression from
      
      	(A - B) - C  to  A - (B + C)
      
      This makes the code look a little nicer too.
      
      Cc: John W. Linville <linville@tuxdriver.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      f6195aa0
  8. 01 9月, 2010 6 次提交
    • D
      lockup_detector: Sync touch_*_watchdog back to old semantics · 68d3f1d8
      Don Zickus 提交于
      During my rewrite, the semantics of touch_nmi_watchdog and
      touch_softlockup_watchdog changed enough to break some drivers
      (mostly over preemptable regions).
      
      These are cases where long delays on one CPU (due to
      print_delay for example) can cause long delays on other
      CPUs - so we must 'touch' the nmi_watchdog flag of those
      other CPUs as well.
      
      This change brings those touch_*_watchdog() functions back in line
      with to how they used to work.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: peterz@infradead.org
      Cc: fweisbec@gmail.com
      LKML-Reference: <1283310009-22168-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      68d3f1d8
    • C
      perf, x86, Pentium4: Add RAW events verification · c9cf4a01
      Cyrill Gorcunov 提交于
      Implements verification of
      
      - Bits of ESCR EventMask field (meaningful bits in field are hardware
        predefined and others bits should be set to zero)
      
      - INSTR_COMPLETED event (it is available on predefined cpu model only)
      
      - Thread shared events (they should be guarded by "perf_event_paranoid"
        sysctl due to security reason). The side effect of this action is
        that PERF_COUNT_HW_BUS_CYCLES become a "paranoid" general event.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Tested-by: NLin Ming <ming.m.lin@intel.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20100825182334.GB14874@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c9cf4a01
    • A
      lockup_detector: Remove unused panic_notifier · 14416c35
      Akinobu Mita 提交于
      The panic notifer in lockup_detector just set did_panic to 1.
      But did_panic is not used anywhere so we can just remove it.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: peterz@infradead.org
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      LKML-Reference: <1283310009-22168-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      14416c35
    • A
      lockup_detector: Convert cpu notifier to return encapsulate errno value · eac24335
      Akinobu Mita 提交于
      By the commit e6bde73b
      ("cpu-hotplug: return better errno on cpu hotplug failure"),
      the cpu notifier can return encapsulate errno value, resulting
      in more meaningful error codes for CPU hotplug failures.
      
      This converts the cpu notifier to return encapsulate errno value
      for the lockup_detector as well.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: peterz@infradead.org
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      LKML-Reference: <1283310009-22168-3-git-send-email-dzickus@redhat.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      eac24335
    • L
      tracing: Fix a race in function profile · 3aaba20f
      Li Zefan 提交于
      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: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: stable@kernel.org
      LKML-Reference: <4C723644.4040708@cn.fujitsu.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      3aaba20f
    • S
      tracing/lockdep: Fix dependency of TRACE_IRQFLAGS · 46b93b74
      Steven Rostedt 提交于
      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: NRichard Kennedy <richard@rsk.demon.co.uk>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      46b93b74
  9. 31 8月, 2010 1 次提交
  10. 30 8月, 2010 2 次提交
    • S
      perf_events: Fix time tracking for events with pid != -1 and cpu != -1 · fa66f07a
      Stephane Eranian 提交于
      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: NStephane Eranian <eranian@gmail.com>
      Acked-by: NPeter 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: NIngo Molnar <mingo@elte.hu>
      fa66f07a
    • I
      Merge branch 'perf/core' of... · 3449dafa
      Ingo Molnar 提交于
      Merge branch 'perf/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into perf/core
      3449dafa
  11. 27 8月, 2010 2 次提交
    • F
      Merge branch 'perf/urgent' into perf/core · 98ee74a7
      Frederic Weisbecker 提交于
      Conflicts:
      	tools/perf/util/callchain.h
      
      Merge reason:
      	Fix a non-trivial conflict with latest fixes
      98ee74a7
    • F
      perf: Initialize callchains roots's childen hits · 5225c458
      Frederic Weisbecker 提交于
      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: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NFrederic 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
  12. 26 8月, 2010 5 次提交