02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
19 Jan, 2017
2 commits
-
The unlikely/likely branch profiler now gets called even if the if statement
is a constant (always goes in one direction without a compare). Add a value
to denote this in the likely/unlikely tracer as well.Signed-off-by: Steven Rostedt (VMware)
-
Now that constants are traced, it is useful to see the number of constants
that are traced in the likely/unlikely profiler in order to know if they
should be ignored or not.The likely/unlikely will display a number after the "correct" number if a
"constant" count exists.Signed-off-by: Steven Rostedt (VMware)
18 Jan, 2017
1 commit
-
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.Signed-off-by: Steven Rostedt (VMware)
24 Nov, 2016
1 commit
-
The function __buffer_unlock_commit() is called in a few places outside of
trace.c. But for the most part, it should really be inlined, as it is in the
hot path of the trace_events. For the callers outside of trace.c, create a
new function trace_buffer_unlock_commit_nostack(), as the reason it was used
was to avoid the stack tracing that trace_buffer_unlock_commit() could do.Link: http://lkml.kernel.org/r/20161121183700.GW26852@two.firstfloor.org
Reported-by: Andi Kleen
Signed-off-by: Steven Rostedt
21 Oct, 2015
1 commit
-
Both start_branch_trace() and stop_branch_trace() are used in only one
location, and are both static. As they are small functions there is no
need to keep them separated out.Link: http://lkml.kernel.org/r/1445000689-32596-1-git-send-email-0x7f454c46@gmail.com
Signed-off-by: Dmitry Safonov
Signed-off-by: Steven Rostedt
08 Jul, 2015
1 commit
-
Fengguang Wu's tests triggered a bug in the branch tracer's start up
test when CONFIG_DEBUG_PREEMPT set. This was because that config
adds some debug logic in the per cpu field, which calls back into
the branch tracer.The branch tracer has its own recursive checks, but uses a per cpu
variable to implement it. If retrieving the per cpu variable calls
back into the branch tracer, you can see how things will break.Instead of using a per cpu variable, use the trace_recursion field
of the current task struct. Simply set a bit when entering the
branch tracing and clear it when leaving. If the bit is set on
entry, just don't do the tracing.There's also the case with lockdep, as the local_irq_save() called
before the recursion can also trigger code that can call back into
the function. Changing that to a raw_local_irq_save() will protect
that as well.This prevents the recursion and the inevitable crash that follows.
Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.com
Cc: stable@vger.kernel.org # 3.10+
Reported-by: Fengguang Wu
Tested-by: Fengguang Wu
Signed-off-by: Steven Rostedt
14 May, 2015
2 commits
-
The name "ftrace" really refers to the function hook infrastructure. It
is not about the trace_events. The structures ftrace_event_call and
ftrace_event_class have nothing to do with the function hooks, and are
really trace_event structures. Rename ftrace_event_* to trace_event_*.Signed-off-by: Steven Rostedt
-
The name "ftrace" really refers to the function hook infrastructure. It
is not about the trace_events. The functions (un)register_ftrace_event() is
really about trace_events, and the name should be register_trace_event()
instead.Also renamed ftrace_event_reg() to trace_event_reg() for the same reason.
Signed-off-by: Steven Rostedt
23 Jan, 2015
1 commit
-
The creation of tracing files and directories is for the most part
encapsulated in helper functions in trace.c. Other files do not need to
include debugfs.h or fs.h, as they may have needed to in the past.Remove them from the files that do not need them.
Signed-off-by: Steven Rostedt
20 Nov, 2014
1 commit
-
The branch tracer should not be checking the trace_seq_printf() return value
as that will soon be void. There's a new trace_handle_return() helper function
that will return TRACE_TYPE_PARTIAL_LINE if the trace_seq overflowed
and TRACE_TYPE_HANDLED otherwise.Reviewed-by: Petr Mladek
Signed-off-by: Steven Rostedt
14 Nov, 2014
2 commits
-
Consecutive seq_puts calls with literal strings can be merged to a
single call. This reduces the size of the generated code, and can also
lead to slight .rodata reduction (because of fewer nul and padding
bytes). It should also shave a off a few clock cycles.Link: http://lkml.kernel.org/r/1415479332-25944-3-git-send-email-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes
Signed-off-by: Steven Rostedt -
Using seq_printf to print a simple string or a single character is a
lot more expensive than it needs to be, since seq_puts and seq_putc
exist.These patches do
seq_printf(m, s) -> seq_puts(m, s)
seq_printf(m, "%s", s) -> seq_puts(m, s)
seq_printf(m, "%c", c) -> seq_putc(m, c)Subsequent patches will simplify further.
Link: http://lkml.kernel.org/r/1415479332-25944-2-git-send-email-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes
Signed-off-by: Steven Rostedt
06 Nov, 2013
1 commit
-
The trace event filters are still tied to event calls rather than
event files, which means you don't get what you'd expect when using
filters in the multibuffer case:Before:
# echo 'bytes_alloc > 8192' > /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
# cat /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
bytes_alloc > 8192
# mkdir /sys/kernel/debug/tracing/instances/test1
# echo 'bytes_alloc > 2048' > /sys/kernel/debug/tracing/instances/test1/events/kmem/kmalloc/filter
# cat /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
bytes_alloc > 2048
# cat /sys/kernel/debug/tracing/instances/test1/events/kmem/kmalloc/filter
bytes_alloc > 2048Setting the filter in tracing/instances/test1/events shouldn't affect
the same event in tracing/events as it does above.After:
# echo 'bytes_alloc > 8192' > /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
# cat /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
bytes_alloc > 8192
# mkdir /sys/kernel/debug/tracing/instances/test1
# echo 'bytes_alloc > 2048' > /sys/kernel/debug/tracing/instances/test1/events/kmem/kmalloc/filter
# cat /sys/kernel/debug/tracing/events/kmem/kmalloc/filter
bytes_alloc > 8192
# cat /sys/kernel/debug/tracing/instances/test1/events/kmem/kmalloc/filter
bytes_alloc > 2048We'd like to just move the filter directly from ftrace_event_call to
ftrace_event_file, but there are a couple cases that don't yet have
multibuffer support and therefore have to continue using the current
event_call-based filters. For those cases, a new USE_CALL_FILTER bit
is added to the event_call flags, whose main purpose is to keep the
old behavior for those cases until they can be updated with
multibuffer support; at that point, the USE_CALL_FILTER flag (and the
new associated call_filter_check_discard() function) can go away.The multibuffer support also made filter_current_check_discard()
redundant, so this change removes that function as well and replaces
it with filter_check_discard() (or call_filter_check_discard() as
appropriate).Link: http://lkml.kernel.org/r/f16e9ce4270c62f46b2e966119225e1c3cca7e60.1382620672.git.tom.zanussi@linux.intel.com
Signed-off-by: Tom Zanussi
Signed-off-by: Steven Rostedt
15 Mar, 2013
2 commits
-
The changce to add the trace_buffer struct to have the trace array
have both the main buffer and max buffer broke the branch tracer
because the change did not update that code. As the branch tracer
adds a significant amount of overhead, and must be selected via
a selection (not a allyesconfig) it was missed in testing.Reported-by: Fengguang Wu
Signed-off-by: Steven Rostedt -
The global and max-tr currently use static per_cpu arrays for the CPU data
descriptors. But in order to get new allocated trace_arrays, they need to
be allocated per_cpu arrays. Instead of using the static arrays, switch
the global and max-tr to use allocated data.Signed-off-by: Steven Rostedt
01 Nov, 2012
2 commits
-
Whenever an event is registered, the comm of tasks are saved at
every task switch instead of saving them at every event. But if
an event isn't executed much, the comm cache will be filled up
by tasks that did not record the event and you lose out on the comms
that did.Here's an example, if you enable the following events:
echo 1 > /debug/tracing/events/kvm/kvm_cr/enable
echo 1 > /debug/tracing/events/net/net_dev_xmit/enableNote, there's no kvm running on this machine so the first event will
never be triggered, but because it is enabled, the storing of comms
will continue. If we now disable the network event:echo 0 > /debug/tracing/events/net/net_dev_xmit/enable
and look at the trace:
cat /debug/tracing/trace
sshd-2672 [001] ..s2 375.731616: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s1 375.731617: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s2 375.859356: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s1 375.859357: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s2 375.947351: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s1 375.947352: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s2 376.035383: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s1 376.035383: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
sshd-2672 [001] ..s2 377.563806: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=226 rc=0
sshd-2672 [001] ..s1 377.563807: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=226 rc=0
sshd-2672 [001] ..s2 377.563834: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6be0 len=114 rc=0
sshd-2672 [001] ..s1 377.563842: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6be0 len=114 rc=0We see that process 2672 which triggered the events has the comm "sshd".
But if we run hackbench for a bit and look again:cat /debug/tracing/trace
-2672 [001] ..s2 375.731616: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s1 375.731617: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s2 375.859356: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s1 375.859357: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s2 375.947351: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s1 375.947352: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s2 376.035383: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s1 376.035383: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=242 rc=0
-2672 [001] ..s2 377.563806: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6de0 len=226 rc=0
-2672 [001] ..s1 377.563807: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6de0 len=226 rc=0
-2672 [001] ..s2 377.563834: net_dev_xmit: dev=eth0 skbaddr=ffff88005cbb6be0 len=114 rc=0
-2672 [001] ..s1 377.563842: net_dev_xmit: dev=br0 skbaddr=ffff88005cbb6be0 len=114 rc=0The stored "sshd" comm has been flushed out and we get a useless "".
But by only storing comms after a trace event occurred, we can run
hackbench all day and still get the same output.Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Steven Rostedt -
There's times during debugging that it is helpful to see traces of early
boot functions. But the tracers are initialized at device_initcall()
which is quite late during the boot process. Setting the kernel command
line parameter ftrace=function will not show anything until the function
tracer is initialized. This prevents being able to trace functions before
device_initcall().There's no reason that the tracers need to be initialized so late in the
boot process. Move them up to core_initcall() as they still need to come
after early_initcall() which initializes the tracing buffers.Cc: Thomas Gleixner
Signed-off-by: Steven Rostedt
15 May, 2010
1 commit
-
Multiple events may use the same method to print their data.
Instead of having all events have a pointer to their print funtions,
the trace_event structure now points to a trace_event_functions structure
that will hold the way to print ouf the event.The event itself is now passed to the print function to let the print
function know what kind of event it should print.This opens the door to consolidating the way several events print
their output.text data bss dec hex filename
4913961 1088356 861512 6863829 68bbd5 vmlinux.orig
4900382 1048964 861512 6810858 67ecea vmlinux.init
4900446 1049028 861512 6810986 67ed6a vmlinux.preprintThis change slightly increases the size but is needed for the next change.
v3: Fix the branch tracer events to handle this change.
v2: Fix the new function graph tracer event calls to handle this change.
Acked-by: Mathieu Desnoyers
Acked-by: Masami Hiramatsu
Acked-by: Frederic Weisbecker
Signed-off-by: Steven Rostedt
10 Feb, 2010
1 commit
-
The branch annotation is a bit difficult to see the worst offenders
because it only sorts by percentage:correct incorrect % Function File Line
------- --------- - -------- ---- ----
0 163 100 qdisc_restart sch_generic.c 179
0 163 100 pfifo_fast_dequeue sch_generic.c 447
0 4 100 pskb_trim_rcsum skbuff.h 1689
0 4 100 llc_rcv llc_input.c 170
0 18 100 psmouse_interrupt psmouse-base.c 304
0 3 100 atkbd_interrupt atkbd.c 389
0 5 100 usb_alloc_dev usb.c 437
0 11 100 vsscanf vsprintf.c 1897
0 2 100 IS_ERR err.h 34
0 23 100 __rmqueue_fallback page_alloc.c 865
0 4 100 probe_wakeup_sched_switch trace_sched_wakeup.c 142
0 3 100 move_masked_irq migration.c 11Adding the incorrect and correct values as sort keys makes this file a
bit more informative:correct incorrect % Function File Line
------- --------- - -------- ---- ----
0 366541 100 audit_syscall_entry auditsc.c 1637
0 366538 100 audit_syscall_exit auditsc.c 1685
0 115839 100 sched_info_switch sched_stats.h 269
0 74567 100 sched_info_queued sched_stats.h 222
0 66578 100 sched_info_dequeued sched_stats.h 177
0 15113 100 trace_workqueue_insertion workqueue.h 38
0 15107 100 trace_workqueue_execution workqueue.h 45
0 3622 100 syscall_trace_leave ptrace.c 1772
0 2750 100 sched_move_task sched.c 10100
0 2750 100 sched_move_task sched.c 10110
0 1815 100 pre_schedule_rt sched_rt.c 1462
0 837 100 audit_alloc auditsc.c 879
0 814 100 tcp_mss_split_point tcp_output.c 1302Signed-off-by: Steven Rostedt
08 Oct, 2009
2 commits
-
Just using the tr->buffer for the API to trace_buffer_lock_reserve
is not good enough. This is because the tr->buffer may change, and we
do not want to commit with a different buffer that we reserved from.This patch uses a local variable to hold the buffer that was used to
reserve and commit with.Signed-off-by: Steven Rostedt
-
fix warnings that caused the API change of trace_buffer_lock_reserve()
change files: kernel/trace/trace_hw_branch.c
kernel/trace/trace_branch.cSigned-off-by: Zhenwen Xu
LKML-Reference:
Signed-off-by: Steven Rostedt
07 May, 2009
1 commit
-
Merge reason: tracing/core was on a .30-rc1 base and was missing out on
on a handful of tracing fixes present in .30-rc5-almost.Signed-off-by: Ingo Molnar
14 Apr, 2009
3 commits
-
Before patch:
# tracer: branch
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
-2981 [000] 24008.872738: [ ok ] trace_irq_handler_exit:irq_event_types.h:41
-2981 [000] 24008.872742: [ ok ] note_interrupt:spurious.c:229
...After patch:
# tracer: branch
#
# TASK-PID CPU# TIMESTAMP CORRECT FUNC:FILE:LINE
# | | | | | |
-2985 [000] 26329.142970: [ ok ] slab_free:slub.c:1776
-2985 [000] 26329.142972: [ ok ] trace_kmem_cache_free:kmem_event_types.h:191
...Signed-off-by: Zhao Lei
Acked-by: Frederic Weisbecker
Cc: Steven Rostedt
Cc: Tom Zanussi
LKML-Reference:
Signed-off-by: Ingo Molnar -
This patch changes filter_check_discard() to make use of the new
ring_buffer_discard_commit() function and modifies the current users to
call the old commit function in the non-discard case.It also introduces a version of filter_check_discard() that uses the
global trace buffer (filter_current_check_discard()) for those cases.v2 changes:
- fix compile error noticed by Ingo Molnar
Signed-off-by: Tom Zanussi
Cc: Steven Rostedt
Cc: fweisbec@gmail.com
LKML-Reference:
Signed-off-by: Ingo Molnar -
This patch adds run-time field descriptions to all the event formats
exported using TRACE_EVENT_FORMAT. It also hooks up all the tracers
that use them (i.e. the tracers in the 'ftrace subsystem') so they can
also have their output filtered by the event-filtering mechanism.When I was testing this, there were a couple of things that fooled me
into thinking the filters weren't working, when actually they were -
I'll mention them here so others don't make the same mistakes (and file
bug reports. ;-)One is that some of the tracers trace multiple events e.g. the
sched_switch tracer uses the context_switch and wakeup events, and if
you don't set filters on all of the traced events, the unfiltered output
from the events without filters on them can make it look like the
filtering as a whole isn't working properly, when actually it is doing
what it was asked to do - it just wasn't asked to do the right thing.The other is that for the really high-volume tracers e.g. the function
tracer, the volume of filtered events can be so high that it pushes the
unfiltered events out of the ring buffer before they can be read so e.g.
cat'ing the trace file repeatedly shows either no output, or once in
awhile some output but that isn't there the next time you read the
trace, which isn't what you normally expect when reading the trace file.
If you read from the trace_pipe file though, you can catch them before
they disappear.Changes from v1:
As suggested by Frederic Weisbecker:
- get rid of externs in functions
- added unlikely() to filter_check_discard()Signed-off-by: Tom Zanussi
Signed-off-by: Steven Rostedt
Signed-off-by: Ingo Molnar
25 Mar, 2009
1 commit
-
Currently, if a trace_stat user wants a handle to some private data,
the trace_stat infrastructure does not supply a way to do that.This patch passes the trace_stat structure to the start function of
the trace_stat code.Signed-off-by: Steven Rostedt
11 Mar, 2009
1 commit
-
Impact: clean up
There existed a lot of 's in the tracing code. This
patch removes them.Signed-off-by: Steven Rostedt
05 Mar, 2009
1 commit
-
Impact: clean up
The trace and latency_trace function pointers are identical for
every tracer but the function tracer. The differences in the function
tracer are trivial (latency output puts paranthesis around parent).This patch removes the latency_trace pointer and all prints will
now just use the trace output function pointer.Signed-off-by: Steven Rostedt
11 Feb, 2009
1 commit
-
Impact: clean up.
Remove the unnecessary variable ret.
Signed-off-by: Wenji Huang
Signed-off-by: Steven Rostedt
06 Feb, 2009
3 commits
-
Impact: cleanup
To make it easy for ftrace plugin writers, as this was open coded in
the existing pluginsSigned-off-by: Arnaldo Carvalho de Melo
Acked-by: Frédéric Weisbecker
Signed-off-by: Ingo Molnar -
Impact: new API
These new functions do what previously was being open coded, reducing
the number of details ftrace plugin writers have to worry about.It also standardizes the handling of stacktrace, userstacktrace and
other trace options we may introduce in the future.With this patch, for instance, the blk tracer (and some others already
in the tree) can use the "userstacktrace" /d/tracing/trace_options
facility.$ codiff /tmp/vmlinux.before /tmp/vmlinux.after
linux-2.6-tip/kernel/trace/trace.c:
trace_vprintk | -5
trace_graph_return | -22
trace_graph_entry | -26
trace_function | -45
__ftrace_trace_stack | -27
ftrace_trace_userstack | -29
tracing_sched_switch_trace | -66
tracing_stop | +1
trace_seq_to_user | -1
ftrace_trace_special | -63
ftrace_special | +1
tracing_sched_wakeup_trace | -70
tracing_reset_online_cpus | -1
13 functions changed, 2 bytes added, 355 bytes removed, diff: -353linux-2.6-tip/block/blktrace.c:
__blk_add_trace | -58
1 function changed, 58 bytes removed, diff: -58linux-2.6-tip/kernel/trace/trace.c:
trace_buffer_lock_reserve | +88
trace_buffer_unlock_commit | +86
2 functions changed, 174 bytes added, diff: +174/tmp/vmlinux.after:
16 functions changed, 176 bytes added, 413 bytes removed, diff: -237Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frédéric Weisbecker
Signed-off-by: Ingo Molnar -
Impact: API change, cleanup
>From ring_buffer_{lock_reserve,unlock_commit}.
$ codiff /tmp/vmlinux.before /tmp/vmlinux.after
linux-2.6-tip/kernel/trace/trace.c:
trace_vprintk | -14
trace_graph_return | -14
trace_graph_entry | -10
trace_function | -8
__ftrace_trace_stack | -8
ftrace_trace_userstack | -8
tracing_sched_switch_trace | -8
ftrace_trace_special | -12
tracing_sched_wakeup_trace | -8
9 functions changed, 90 bytes removed, diff: -90linux-2.6-tip/block/blktrace.c:
__blk_add_trace | -1
1 function changed, 1 bytes removed, diff: -1/tmp/vmlinux.after:
10 functions changed, 91 bytes removed, diff: -91Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frédéric Weisbecker
Signed-off-by: Ingo Molnar
05 Feb, 2009
4 commits
-
Impact: cleanup
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Steven Rostedt
Signed-off-by: Ingo Molnar -
Impact: simplification of tracers
As all tracers are doing this we might as well do it in
register_ftrace_event and save one branch each time we call these
callbacks.Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frederic Weisbecker
Acked-by: Steven Rostedt
Signed-off-by: Ingo Molnar -
As they actually all return these enumerators.
Reported-by: Frederic Weisbecker
Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frederic Weisbecker
Signed-off-by: Ingo Molnar -
Impact: bugfix and cleanup
Some callsites were returning either TRACE_ITER_PARTIAL_LINE if the
trace_seq routines (trace_seq_printf, etc) returned 0 meaning its buffer
was full, or zero otherwise.But...
/* Return values for print_line callback */
enum print_line_t {
TRACE_TYPE_PARTIAL_LINE = 0, /* Retry after flushing the seq */
TRACE_TYPE_HANDLED = 1,
TRACE_TYPE_UNHANDLED = 2 /* Relay to other output functions */
};In other cases the return value was not being relayed at all.
Most of the time it didn't hurt because the page wasn't get filled, but
for correctness sake, handle the return values everywhere.Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frederic Weisbecker
Signed-off-by: Ingo Molnar
03 Feb, 2009
1 commit
-
Impact: API change
The trace_seq and trace_entry are in trace_iterator, where there are
more fields that may be needed by tracers, so just pass the
tracer_iterator as is already the case for struct tracer->print_line.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Ingo Molnar
29 Jan, 2009
1 commit
-
Impact: cleanup
Signed-off-by: Arnaldo Carvalho de Melo
Acked-by: Frédéric Weisbecker
Signed-off-by: Ingo Molnar
14 Jan, 2009
1 commit
-
Impact: tracing's Api change
Currently, the stat tracing depends on the events tracing.
When you switch to a new tracer, the stats files of the previous tracer
will disappear. But it's more scalable to separate those two engines.
This way, we can keep the stat files of one or several tracers when we
want, without bothering of multiple tracer stat files or tracer switching.To build/destroys its stats files, a tracer just have to call
register_stat_tracer/unregister_stat_tracer everytimes it wants to.Signed-off-by: Frederic Weisbecker
Signed-off-by: Steven Rostedt
Signed-off-by: Ingo Molnar
