1. 18 Jun, 2012 17 commits
  2. 16 Jun, 2012 15 commits
  3. 15 Jun, 2012 1 commit
  4. 14 Jun, 2012 4 commits
    • Steven Rostedt's avatar
      tracing: Register the ftrace internal events during early boot · 7374e827
      Steven Rostedt authored
      All trace events including ftrace internel events (like trace_printk
      and function tracing), register functions that describe how to print
      their output. The events may be recorded as soon as the ring buffer
      is allocated, but they are just raw binary in the buffer. The mapping
      of event ids to how to print them are held within a structure that
      is registered on system boot.
      
      If a crash happens in boot up before these functions are registered
      then their output (via ftrace_dump_on_oops) will be useless:
      
      Dumping ftrace buffer:
      ---------------------------------
         <...>-1       0.... 319705us : Unknown type 6
      ---------------------------------
      
      This can be quite frustrating for a kernel developer trying to see
      what is going wrong.
      
      There's no reason to register them so late in the boot up process.
      They can be registered by early_initcall().
      Reported-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      7374e827
    • Steven Rostedt's avatar
      tracing: Add comments for the other bits of ftrace_event_call.flags · 5da43bed
      Steven Rostedt authored
      	TRACE_EVENT_FL_ENABLED_BIT,
      	TRACE_EVENT_FL_FILTERED_BIT,
      	TRACE_EVENT_FL_RECORDED_CMD_BIT,
      
      Have comments about what they are, but:
      
      	TRACE_EVENT_FL_CAP_ANY_BIT,
      	TRACE_EVENT_FL_NO_SET_FILTER_BIT,
      	TRACE_EVENT_FL_IGNORE_ENABLE_BIT,
      
      do not, making them second class citizens. To prevent another
      class warfare, these bits have protested for their right to be
      commented. And By Golly! I'll give them what they want!
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      5da43bed
    • Borislav Petkov's avatar
      ftrace: Remove a superfluous check · 8d240dd8
      Borislav Petkov authored
      register_ftrace_function() checks ftrace_disabled and calls
      __register_ftrace_function which does it again.
      
      Drop the first check and add the unlikely hint to the second one. Also,
      drop the label as John correctly notices.
      
      No functional change.
      
      Link: http://lkml.kernel.org/r/20120329171140.GE6409@aftab
      
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: John Kacur <jkacur@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      8d240dd8
    • Don Zickus's avatar
      watchdog: Quiet down the boot messages · a7027046
      Don Zickus authored
      A bunch of bugzillas have complained how noisy the nmi_watchdog
      is during boot-up especially with its expected failure cases
      (like virt and bios resource contention).
      
      This is my attempt to quiet them down and keep it less confusing
      for the end user.  What I did is print the message for cpu0 and
      save it for future comparisons.  If future cpus have an
      identical message as cpu0, then don't print the redundant info.
      However, if a future cpu has a different message, happily print
      that loudly.
      
      Before the change, you would see something like:
      
          ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
          CPU0: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz stepping 0a
          Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
          ... version:                2
          ... bit width:              40
          ... generic registers:      2
          ... value mask:             000000ffffffffff
          ... max period:             000000007fffffff
          ... fixed-purpose events:   3
          ... event mask:             0000000700000003
          NMI watchdog enabled, takes one hw-pmu counter.
          Booting Node   0, Processors  #1
          NMI watchdog enabled, takes one hw-pmu counter.
           #2
          NMI watchdog enabled, takes one hw-pmu counter.
           #3 Ok.
          NMI watchdog enabled, takes one hw-pmu counter.
          Brought up 4 CPUs
          Total of 4 processors activated (22607.24 BogoMIPS).
      
      After the change, it is simplified to:
      
          ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
          CPU0: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz stepping 0a
          Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
          ... version:                2
          ... bit width:              40
          ... generic registers:      2
          ... value mask:             000000ffffffffff
          ... max period:             000000007fffffff
          ... fixed-purpose events:   3
          ... event mask:             0000000700000003
          NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
          Booting Node   0, Processors  #1 #2 #3 Ok.
          Brought up 4 CPUs
      
      V2: little changes based on Joe Perches' feedback
      V3: printk cleanup based on Ingo's feedback; checkpatch fix
      V4: keep printk as one long line
      V5: Ingo fix ups
      Reported-and-tested-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: nzimmer@sgi.com
      Cc: joe@perches.com
      Link: http://lkml.kernel.org/r/1339594548-17227-1-git-send-email-dzickus@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a7027046
  5. 13 Jun, 2012 1 commit
  6. 12 Jun, 2012 1 commit
    • Arnaldo Carvalho de Melo's avatar
      perf tools: Fix synthesizing tracepoint names from the perf.data headers · cb9dd49e
      Arnaldo Carvalho de Melo authored
      We need to use the per event info snapshoted at record time to
      synthesize the events name, so do it just after reading the perf.data
      headers, when we already processed the /sys events data, otherwise we'll
      end up using the local /sys that only by sheer luck will have the same
      tracepoint ID -> real event association.
      
      Example:
      
        # uname -a
        Linux felicio.ghostprotocols.net 3.4.0-rc5+ #1 SMP Sat May 19 15:27:11 BRT 2012 x86_64 x86_64 x86_64 GNU/Linux
        # perf record -e sched:sched_switch usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.015 MB perf.data (~648 samples) ]
        # cat /t/events/sched/sched_switch/id
        279
        # perf evlist -v
        sched:sched_switch: sample_freq=1, type: 2, config: 279, size: 80, sample_type: 1159, read_format: 7, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1
        #
      
      So on the above machine the sched:sched_switch has tracepoint id 279, but on
      the machine were we'll analyse it it has a different id:
      
        $ cat /t/events/sched/sched_switch/id
        56
        $ perf evlist -i /tmp/perf.data
        kmem:mm_balancedirty_writeout
        $ cat /t/events/kmem/mm_balancedirty_writeout/id
        279
      
      With this fix:
      
        $ perf evlist -i /tmp/perf.data
        sched:sched_switch
      Reported-by: default avatarDmitry Antipov <dmitry.antipov@linaro.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-auwks8fpuhmrdpiefs55o5oz@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      cb9dd49e
  7. 11 Jun, 2012 1 commit
    • Stephane Eranian's avatar
      perf stat: Fix default output file · fc3e4d07
      Stephane Eranian authored
      The following commit:
      
      commit 56f3bae7
      Author: Jim Cromie <jim.cromie@gmail.com>
      Date:   Wed Sep 7 17:14:00 2011 -0600
      
          perf stat: Add --log-fd <N> option to redirect stderr elsewhere
      
      introduced a bug in the way perf stat outputs the results by default,
      i.e., without the --log-fd or --output option. It would default to
      writing to file descriptor 0, i.e., stdin. Writing to stdin is allowed
      and is equivalent to writing to stdout. However, there is a major
      difference for any script that was already capturing the output of perf
      stat via redirection:
      
          perf stat >/tmp/log .... or perf stat 2>/tmp/log ....
      
      They would not capture anything anymore. They would have to do:
          perf stat 0>/tmp/log ...
      
      This breaks compatibility with existing scripts and does not look very
      natural.
      
      This patch fixes the problem by looking at output_fd only when it was
      modified by user (> 0). It also checks that the value if positive.
      Passing --log-fd 0 is ignored.
      
      I would also argue that defaulting to stderr for the results is not the
      right thing to do, though this patch does not address this specific
      issue.
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jim Cromie <jim.cromie@gmail.com>
      Link: http://lkml.kernel.org/r/20120515111111.GA9870@quadSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      fc3e4d07