19 May, 2011

2 commits


07 Jan, 2011

1 commit


23 Oct, 2010

1 commit


20 Jul, 2010

2 commits

  • Special traces type was only used by sysprof. Lets remove it now
    that sysprof ftrace plugin has been dropped.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Soeren Sandmann
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Steven Rostedt
    Cc: Li Zefan

    Frederic Weisbecker
     
  • The sysprof ftrace plugin doesn't seem to be seriously used
    somewhere. There is a branch in the sysprof tree that makes
    an interface to it, but the real sysprof tool uses either its
    own module or perf events.

    Drop the sysprof ftrace plugin then, as it's mostly useless.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Soeren Sandmann
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Steven Rostedt
    Cc: Li Zefan

    Frederic Weisbecker
     

16 Jul, 2010

1 commit

  • The ksym (breakpoint) ftrace plugin has been superseded by perf
    tools that are much more poweful to use the cpu breakpoints.
    This tracer doesn't bring more feature. It has been deprecated
    for a while now, lets remove it.

    Signed-off-by: Frederic Weisbecker
    Cc: Steven Rostedt
    Cc: Prasad
    Cc: Ingo Molnar

    Frederic Weisbecker
     

18 May, 2010

2 commits

  • …el/git/tip/linux-2.6-tip

    * 'tracing-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    tracing: Fix "integer as NULL pointer" warning.
    tracing: Fix tracepoint.h DECLARE_TRACE() to allow more than one header
    tracing: Make the documentation clear on trace_event boot option
    ring-buffer: Wrap open-coded WARN_ONCE
    tracing: Convert nop macros to static inlines
    tracing: Fix sleep time function profiling
    tracing: Show sample std dev in function profiling
    tracing: Add documentation for trace commands mod, traceon/traceoff
    ring-buffer: Make benchmark handle missed events
    ring-buffer: Make non-consuming read less expensive with lots of cpus.
    tracing: Add graph output support for irqsoff tracer
    tracing: Have graph flags passed in to ouput functions
    tracing: Add ftrace events for graph tracer
    tracing: Dump either the oops's cpu source or all cpus buffers
    tracing: Fix uninitialized variable of tracing/trace output

    Linus Torvalds
     
  • …git/tip/linux-2.6-tip

    * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (311 commits)
    perf tools: Add mode to build without newt support
    perf symbols: symbol inconsistency message should be done only at verbose=1
    perf tui: Add explicit -lslang option
    perf options: Type check all the remaining OPT_ variants
    perf options: Type check OPT_BOOLEAN and fix the offenders
    perf options: Check v type in OPT_U?INTEGER
    perf options: Introduce OPT_UINTEGER
    perf tui: Add workaround for slang < 2.1.4
    perf record: Fix bug mismatch with -c option definition
    perf options: Introduce OPT_U64
    perf tui: Add help window to show key associations
    perf tui: Make <- exit menus too
    perf newt: Add single key shortcuts for zoom into DSO and threads
    perf newt: Exit browser unconditionally when CTRL+C, q or Q is pressed
    perf newt: Fix the 'A'/'a' shortcut for annotate
    perf newt: Make <- exit the ui_browser
    x86, perf: P4 PMU - fix counters management logic
    perf newt: Make <- zoom out filters
    perf report: Report number of events, not samples
    perf hist: Clarify events_stats fields usage
    ...

    Fix up trivial conflicts in kernel/fork.c and tools/perf/builtin-record.c

    Linus Torvalds
     

22 Apr, 2010

1 commit

  • The ftrace_dump_on_oops kernel parameter, sysctl and sysrq let one
    dump every cpu buffers when an oops or panic happens.

    It's nice when you have few cpus but it may take ages if have many,
    plus you miss the real origin of the problem in all the cpu traces.

    Sometimes, all you need is to dump the cpu buffer that triggered the
    opps, most of the time it is our main interest.

    This patch modifies ftrace_dump_on_oops to handle this choice.

    The ftrace_dump_on_oops kernel parameter, when it comes alone, has
    the same behaviour than before. But ftrace_dump_on_oops=orig_cpu
    will only dump the buffer of the cpu that oops'ed.

    Similarly, sysctl kernel.ftrace_dump_on_oops=1 and
    echo 1 > /proc/sys/kernel/ftrace_dump_on_oops keep their previous
    behaviour. But setting 2 jumps into cpu origin dump mode.

    v2: Fix double setup
    v3: Fix spelling issues reported by Randy Dunlap
    v4: Also update __ftrace_dump in the selftests

    Signed-off-by: Frederic Weisbecker
    Acked-by: David S. Miller
    Acked-by: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Li Zefan
    Cc: Lai Jiangshan

    Frederic Weisbecker
     

08 Apr, 2010

2 commits


01 Apr, 2010

1 commit

  • Currently, when the ring buffer drops events, it does not record
    the fact that it did so. It does inform the writer that the event
    was dropped by returning a NULL event, but it does not put in any
    place holder where the event was dropped.

    This is not a trivial thing to add because the ring buffer mostly
    runs in overwrite (flight recorder) mode. That is, when the ring
    buffer is full, new data will overwrite old data.

    In a produce/consumer mode, where new data is simply dropped when
    the ring buffer is full, it is trivial to add the placeholder
    for dropped events. When there's more room to write new data, then
    a special event can be added to notify the reader about the dropped
    events.

    But in overwrite mode, any new write can overwrite events. A place
    holder can not be inserted into the ring buffer since there never
    may be room. A reader could also come in at anytime and miss the
    placeholder.

    Luckily, the way the ring buffer works, the read side can find out
    if events were lost or not, and how many events. Everytime a write
    takes place, if it overwrites the header page (the next read) it
    updates a "overrun" variable that keeps track of the number of
    lost events. When a reader swaps out a page from the ring buffer,
    it can record this number, perfom the swap, and then check to
    see if the number changed, and take the diff if it has, which would be
    the number of events dropped. This can be stored by the reader
    and returned to callers of the reader.

    Since the reader page swap will fail if the writer moved the head
    page since the time the reader page set up the swap, this gives room
    to record the overruns without worrying about races. If the reader
    sets up the pages, records the overrun, than performs the swap,
    if the swap succeeds, then the overrun variable has not been
    updated since the setup before the swap.

    For binary readers of the ring buffer, a flag is set in the header
    of each sub page (sub buffer) of the ring buffer. This flag is embedded
    in the size field of the data on the sub buffer, in the 31st bit (the size
    can be 32 or 64 bits depending on the architecture), but only 27
    bits needs to be used for the actual size (less actually).

    We could add a new field in the sub buffer header to also record the
    number of events dropped since the last read, but this will change the
    format of the binary ring buffer a bit too much. Perhaps this change can
    be made if the information on the number of events dropped is considered
    important enough.

    Note, the notification of dropped events is only used by consuming reads
    or peeking at the ring buffer. Iterating over the ring buffer does not
    keep this information because the necessary data is only available when
    a page swap is made, and the iterator does not swap out pages.

    Cc: Robert Richter
    Cc: Andi Kleen
    Cc: Li Zefan
    Cc: Arnaldo Carvalho de Melo
    Cc: "Luis Claudio R. Goncalves"
    Cc: Frederic Weisbecker
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

26 Mar, 2010

1 commit

  • Support for the PMU's BTS features has been upstreamed in
    v2.6.32, but we still have the old and disabled ptrace-BTS,
    as Linus noticed it not so long ago.

    It's buggy: TIF_DEBUGCTLMSR is trampling all over that MSR without
    regard for other uses (perf) and doesn't provide the flexibility
    needed for perf either.

    Its users are ptrace-block-step and ptrace-bts, since ptrace-bts
    was never used and ptrace-block-step can be implemented using a
    much simpler approach.

    So axe all 3000 lines of it. That includes the *locked_memory*()
    APIs in mm/mlock.c as well.

    Reported-by: Linus Torvalds
    Signed-off-by: Peter Zijlstra
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Cc: Markus Metzger
    Cc: Steven Rostedt
    Cc: Andrew Morton
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

15 Dec, 2009

1 commit


08 Nov, 2009

2 commits

  • The macro used to be used in both trace_selftest.c and
    trace_ksym.c, but no longer, so remove it from header file.

    Signed-off-by: Li Zefan
    Cc: Prasad
    Signed-off-by: Frederic Weisbecker

    Li Zefan
     
  • This patch rebase the implementation of the breakpoints API on top of
    perf events instances.

    Each breakpoints are now perf events that handle the
    register scheduling, thread/cpu attachment, etc..

    The new layering is now made as follows:

    ptrace kgdb ftrace perf syscall
    \ | / /
    \ | / /
    /
    Core breakpoint API /
    /
    | /
    | /

    Breakpoints perf events

    |
    |

    Breakpoints PMU ---- Debug Register constraints handling
    (Part of core breakpoint API)
    |
    |

    Hardware debug registers

    Reasons of this rewrite:

    - Use the centralized/optimized pmu registers scheduling,
    implying an easier arch integration
    - More powerful register handling: perf attributes (pinned/flexible
    events, exclusive/non-exclusive, tunable period, etc...)

    Impact:

    - New perf ABI: the hardware breakpoints counters
    - Ptrace breakpoints setting remains tricky and still needs some per
    thread breakpoints references.

    Todo (in the order):

    - Support breakpoints perf counter events for perf tools (ie: implement
    perf_bpcounter_event())
    - Support from perf tools

    Changes in v2:

    - Follow the perf "event " rename
    - The ptrace regression have been fixed (ptrace breakpoint perf events
    weren't released when a task ended)
    - Drop the struct hw_breakpoint and store generic fields in
    perf_event_attr.
    - Separate core and arch specific headers, drop
    asm-generic/hw_breakpoint.h and create linux/hw_breakpoint.h
    - Use new generic len/type for breakpoint
    - Handle off case: when breakpoints api is not supported by an arch

    Changes in v3:

    - Fix broken CONFIG_KVM, we need to propagate the breakpoint api
    changes to kvm when we exit the guest and restore the bp registers
    to the host.

    Changes in v4:

    - Drop the hw_breakpoint_restore() stub as it is only used by KVM
    - EXPORT_SYMBOL_GPL hw_breakpoint_restore() as KVM can be built as a
    module
    - Restore the breakpoints unconditionally on kvm guest exit:
    TIF_DEBUG_THREAD doesn't anymore cover every cases of running
    breakpoints and vcpu->arch.switch_db_regs might not always be
    set when the guest used debug registers.
    (Waiting for a reliable optimization)

    Changes in v5:

    - Split-up the asm-generic/hw-breakpoint.h moving to
    linux/hw_breakpoint.h into a separate patch
    - Optimize the breakpoints restoring while switching from kvm guest
    to host. We only want to restore the state if we have active
    breakpoints to the host, otherwise we don't care about messed-up
    address registers.
    - Add asm/hw_breakpoint.h to Kbuild
    - Fix bad breakpoint type in trace_selftest.c

    Changes in v6:

    - Fix wrong header inclusion in trace.h (triggered a build
    error with CONFIG_FTRACE_SELFTEST

    Signed-off-by: Frederic Weisbecker
    Cc: Prasad
    Cc: Alan Stern
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Jan Kiszka
    Cc: Jiri Slaby
    Cc: Li Zefan
    Cc: Avi Kivity
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    Cc: Masami Hiramatsu
    Cc: Paul Mundt

    Frederic Weisbecker
     

07 Sep, 2009

1 commit


06 Aug, 2009

1 commit


03 Jun, 2009

1 commit


07 Apr, 2009

2 commits


22 Mar, 2009

2 commits

  • Instead of using ftrace_dump_on_oops, it's far more convenient
    to have the trace leading up to a self-test failure available
    in /debug/tracing/trace.

    Signed-off-by: Frederic Weisbecker
    Cc: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     
  • Impact: detect tracing related hangs

    Sometimes, with some configs, the function graph tracer can make
    the timer interrupt too much slow, hanging the kernel in an endless
    loop of timer interrupts servicing.

    As suggested by Ingo, this patch brings a watchdog which stops the
    selftest after a defined number of functions traced, definitely
    disabling this tracer.

    For those who want to debug the cause of the function graph trace
    hang, you can pass the ftrace_dump_on_oops kernel parameter to dump
    the traces after this hang detection.

    Signed-off-by: Frederic Weisbecker
    Cc: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

18 Mar, 2009

1 commit

  • Impact: fix a selftest warning

    In some cases, it's possible to see the following warning on irqsoff
    tracer selftest:

    [ 4.640003] Testing tracer irqsoff: ------------[ cut here ]------------
    [ 4.653562] WARNING: at kernel/trace/trace.c:458 update_max_tr_single+0x9a/0xc4()
    [ 4.660000] Hardware name: System Product Name
    [ 4.660000] Modules linked in:
    [ 4.660000] Pid: 301, comm: kstop/1 Not tainted 2.6.29-rc8-tip #35837
    [ 4.660000] Call Trace:
    [ 4.660000] [] warn_slowpath+0x79/0x8f
    [ 4.660000] [] ? put_dec+0x64/0x6b
    [ 4.660000] [] ? getnstimeofday+0x58/0xdd
    [ 4.660000] [] ? clocksource_read+0x3/0xf
    [ 4.660000] [] ? ktime_set+0x8/0x34
    [ 4.660000] [] ? balance_runtime+0x8/0x56
    [ 4.660000] [] ? _spin_lock+0x3/0x10
    [ 4.660000] [] ? ftrace_call+0x5/0x8
    [ 4.660000] [] ? task_cputime_zero+0x3/0x27
    [ 4.660000] [] ? cpupri_set+0x90/0xcb
    [ 4.660000] [] ? _spin_lock_irqsave+0x22/0x34
    [ 4.660000] [] ? cpupri_set+0xbb/0xcb
    [ 4.660000] [] ? _spin_unlock_irqrestore+0x23/0x35
    [ 4.660000] [] ? ring_buffer_reset_cpu+0x27/0x51
    [ 4.660000] [] ? _spin_lock_irqsave+0x22/0x34
    [ 4.660000] [] ? ring_buffer_reset_cpu+0x4a/0x51
    [ 4.660000] [] ? _spin_unlock_irqrestore+0x23/0x35
    [ 4.660000] [] ? trace_hardirqs_off+0x1a/0x1c
    [ 4.660000] [] ? _spin_unlock_irqrestore+0x23/0x35
    [ 4.660000] [] ? ring_buffer_reset_cpu+0x4a/0x51
    [ 4.660000] [] ? cpumask_next+0x15/0x18
    [ 4.660000] [] update_max_tr_single+0x9a/0xc4
    [ 4.660000] [] ? exit_notify+0x16/0xf2
    [ 4.660000] [] check_critical_timing+0xcc/0x11e
    [ 4.660000] [] ? exit_notify+0x16/0xf2
    [ 4.660000] [] ? exit_notify+0x16/0xf2
    [ 4.660000] [] stop_critical_timing+0x8c/0x9f
    [ 4.660000] [] ? forget_original_parent+0xac/0xd0
    [ 4.660000] [] trace_hardirqs_on+0x1a/0x1c
    [ 4.660000] [] forget_original_parent+0xac/0xd0
    [ 4.660000] [] exit_notify+0x16/0xf2
    [ 4.660000] [] do_exit+0x1cb/0x225
    [ 4.660000] [] ? kthread+0x0/0x69
    [ 4.660000] [] kernel_thread_helper+0xd/0x10
    [ 4.660000] ---[ end trace a7919e7f17c0a725 ]---
    [ 4.660164] .. no entries found ..FAILED!

    During the selftest of irqsoff tracer, we do that:

    /* disable interrupts for a bit */
    local_irq_disable();
    udelay(100);
    local_irq_enable();
    /* stop the tracing. */
    tracing_stop();
    /* check both trace buffers */
    ret = trace_test_buffer(tr, NULL);

    If a callsite performs a new max delay with irqs off just after
    tracing_stop, update_max_tr_single() -> ring_buffer_swap_cpu()
    will be called with the buffers disabled by tracing_stop(), hence
    the warning, then ring_buffer_swap_cpu() return -EAGAIN and
    update_max_tr_single() complains.

    Fix it by also stopping the tracer before stopping the tracing globally.
    A similar situation can happen with preemptoff and preemptirqsoff tracers
    where we apply the same fix.

    Reported-by: Ingo Molnar
    Signed-off-by: Frederic Weisbecker
    Acked-by: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

16 Mar, 2009

1 commit

  • Impact: fix a warning during preemptirqsoff selftests

    When the preemptirqsoff selftest fails, we see the following
    warning:

    [ 6.050000] Testing tracer preemptirqsoff: .. no entries found ..
    ------------[ cut here ]------------
    [ 6.060000] WARNING: at kernel/trace/trace.c:688 tracing_start+0x67/0xd3()
    [ 6.060000] Modules linked in:
    [ 6.060000] Pid: 1, comm: swapper Tainted: G
    [ 6.060000] Call Trace:
    [ 6.060000] [] warn_slowpath+0xb1/0x100
    [ 6.060000] [] ? trace_preempt_on+0x35/0x4b
    [ 6.060000] [] ? tracing_start+0x31/0xd3
    [ 6.060000] [] ? tracing_start+0x31/0xd3
    [ 6.060000] [] ? __lock_acquired+0xe6/0x1f2
    [ 6.060000] [] ? tracing_start+0x31/0xd3
    [ 6.060000] [] tracing_start+0x67/0xd3
    [ 6.060000] [] ? irqsoff_tracer_reset+0x2d/0x57
    [ 6.060000] [] trace_selftest_startup_preemptirqsoff+0x1c8/0x1f1
    [ 6.060000] [] register_tracer+0x12f/0x241
    [ 6.060000] [] ? init_irqsoff_tracer+0x0/0x53
    [ 6.060000] [] init_irqsoff_tracer+0x3b/0x53

    This is because in fail case, the preemptirqsoff tracer selftest calls twice
    the tracing_start() function:

    int
    trace_selftest_startup_preemptirqsoff(struct tracer *trace, struct trace_array *tr)
    {
    if (!ret && !count) {
    printk(KERN_CONT ".. no entries found ..");
    ret = -1;
    tracing_start(); reset(tr);
    tracing_start();
    Signed-off-by: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

13 Mar, 2009

2 commits


10 Mar, 2009

1 commit


19 Feb, 2009

3 commits


18 Feb, 2009

2 commits


09 Feb, 2009

1 commit


06 Feb, 2009

1 commit


29 Dec, 2008

1 commit


16 Nov, 2008

2 commits

  • Impact: extend the ->init() method with the ability to fail

    This bring a way to know if the initialization of a tracer successed.
    A tracer must return 0 on success and a traditional error (ie:
    -ENOMEM) if it fails.

    If a tracer fails to init, it is free to print a detailed warn. The
    tracing api will not and switch to a new tracer will just return the
    error from the init callback.

    Note: this will be used for the return tracer.

    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     
  • Impact: fix lockdep disabling itself when function tracing is enabled

    The raw_local_irq_saves used in ftrace is causing problems with
    lockdep. (it thinks the irq flags are out of sync and disables
    itself with a warning)

    The raw ops here are not needed, and the normal local_irq_save is fine.

    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Steven Rostedt