ftrace: kill global_start_up
PATCH 1/1 ftrace: kill global_start_up
global_start_up is read-only and always zero. It seems that 4104d326 "ftrace: Remove global function list and call function directly" simply forgot to remove this no longer used variable.
--- kernel/trace/ftrace.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-)
kernel/trace/ftrace.c +1 -3
@@ -2053,7 +2053,6 @@ static void ftrace_run_update_code(int command)static ftrace_func_t saved_ftrace_func;static int ftrace_start_up; -static int global_start_up;static void control_ops_free (struct ftrace_ops *ops) {
@@ -2117,8 +2116,7 @@ static int ftrace_shutdown(struct ftrace_ops *ops, int command)ftrace_hash_rec_disable (ops,1 ); -if (!global_start_up) - ops->flags &= ~FTRACE_OPS_FL_ENABLED ; + ops->flags &= ~FTRACE_OPS_FL_ENABLED ; command |=FTRACE_UPDATE_CALLS ;
Signature · 1 line
1.5.5.1
Quoted 4 lines · On Sun, 20 Jul 2014 17:18:14 +0200 Oleg Nesterov <[email protected]> wrote:
global_start_upis read-only and always zero. It seems that4104d326"ftrace: Remove global function list and call function directly" simply forgot to remove this no longer used variable.
Sure, just after I got done testing my entire 3.17 queue and posted it for linux-next, you decide to send me yet another fix! ;-)
Thanks, applied.
I'll wait and see what other fixes you send me before I run my 10 hour tests.
-- Steve
Quoted 27 lines
Signed-off-by Oleg Nesterov <[email protected]>--- kernel/trace/ftrace.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-)kernel/trace/ftrace.c +1
-3@@ -2053,7 +2053,6 @@ static void ftrace_run_update_code(int command)static ftrace_func_t saved_ftrace_func;static int ftrace_start_up; -static int global_start_up;static void control_ops_free (struct ftrace_ops *ops) {@@ -2117,8 +2116,7 @@ static int ftrace_shutdown(struct ftrace_ops *ops, int command)ftrace_hash_rec_disable (ops,1 ); -if (!global_start_up) - ops->flags &= ~FTRACE_OPS_FL_ENABLED ; + ops->flags &= ~FTRACE_OPS_FL_ENABLED ; command |=FTRACE_UPDATE_CALLS ;
Steven Rostedt
maintainerQuoted 8 lines · On Mon, 21 Jul 2014 09:47:06 -0400 Steven Rostedt <[email protected]> wrote:
Quoted 4 lines · On Sun, 20 Jul 2014 17:18:14 +0200 Oleg Nesterov <[email protected]> wrote:
global_start_upis read-only and always zero. It seems that4104d326"ftrace: Remove global function list and call function directly" simply forgot to remove this no longer used variable.
Quoted 8 lines
Sure, just after I got done testing my entire 3.17 queue and posted it for linux-next, you decide to send me yet another fix! ;-)
Thanks, applied.
I'll wait and see what other fixes you send me before I run my 10 hour tests.
Nevermind, seems that Namhyung Kim beat you to it (and it's already in my for-next branch).
http://lkml.kernel.org/r/[email protected]
-- Steve
Quoted 17 lines · Steven Rostedt
Quoted 13 lines · On Mon, 21 Jul 2014 09:47:06 -0400 Steven Rostedt <[email protected]> wrote:
Quoted 4 lines · On Sun, 20 Jul 2014 17:18:14 +0200 Oleg Nesterov <[email protected]> wrote:
global_start_upis read-only and always zero. It seems that4104d326"ftrace: Remove global function list and call function directly" simply forgot to remove this no longer used variable.Sure, just after I got done testing my entire 3.17 queue and posted it for linux-next, you decide to send me yet another fix! ;-)
Thanks, applied.
Quoted 8 lines
Quoted 3 lines
I'll wait and see what other fixes you send me before I run my 10 hour tests.
Nevermind, seems that Namhyung Kim beat you to it (and it's already in my for-next branch).
Thanks for your report Steven, I updated my ~/people-i-hate file.
This motivated me to try to find something else unused. And it seems that almost all code in kernel/trace/trace_sched_switch.c is dead? Hmm, and probably even event_context_switch... I'll recheck and send the patch.
But is there any documentation about /sys/kernel/debug/tracing/events/ftrace/* files ?
OK, as I just figured out ftrace/function is special, it is visible to perf and thus "record ftrace:function" should work.
But what a user can do with other files? You obviously can't enable, say, ftrace/bputs, if I understand correctly this is for trace_puts().
Confused...
Oleg.
Steven Rostedt
maintainerQuoted 6 lines · On Wed, 23 Jul 2014 20:29:11 +0200 Oleg Nesterov <[email protected]> wrote:
Quoted 4 lines
Nevermind, seems that Namhyung Kim beat you to it (and it's already in my for-next branch).
Thanks for your report Steven, I updated my ~/people-i-hate file.
Is that for me or Namhyung? Silly question, it has to be for Namhyung, as I'm sure I'm one of the first people already in that list.
Quoted 4 lines
This motivated me to try to find something else unused. And it seems that almost all code in
kernel/trace/trace_sched_switch.cis dead? Hmm, and
sched_switch? Move along, nothing to see here...
OK, there was a time we had a bunch of "tracers" (those things in the available_tracers file). And since events and perf came along, there was a push to remove them all. We never got rid of function, function_graph, mmiotrace and the latency tracers as they are quite different from events (function is close, but they need special care).
One of the casualties to that tracer purge was the sched_switch tracer. But it wasn't such a simple removal, as that code was in charge of the trace_find_cmdline() logic. Well, to get people away from using it, we removed it from the "available_tracers" file, but kept most of the code as clean up for another day.
As with most things on a TODO list, they get pushed down to the bottom, crushed by the many things above it, and finally swept under the rug until some nosy developer decides to take a peek under that carpet and point to the maintainer of said code with his white glove on and the smudge at the end of his finger and say "WHAT'S THIS!".
Well, here's a broom and dustpan, have at it!
Quoted 4 lines
probably even
event_context_switch... I'll recheck and send the patch.But is there any documentation about
/sys/kernel/debug/tracing/events/ftrace/*files ?
No, they are mostly internal, and only there for the format files for things like trace-cmd and perf to be able to parse it.
Quoted 7 lines
OK, as I just figured out ftrace/function is special, it is visible to perf and thus "record ftrace:function" should work.
But what a user can do with other files? You obviously can't enable, say, ftrace/bputs, if I understand correctly this is for
trace_puts().
Yeah, as trace_printk() can turn into a trace_puts() we still want those to be read by trace-cmd. To do that, the formats for those files are exported.
See kernel/trace/trace_export.c and trace_entries.h
Quoted 1 line
Confused...
Aren't we all?
-- Steve
Quoted 8 lines · Steven Rostedt
Quoted 1 line · On Wed, 23 Jul 2014 20:29:11 +0200 Oleg Nesterov <[email protected]> wrote:
Thanks for your report Steven, I updated my ~/people-i-hate file.
Is that for me or Namhyung? Silly question, it has to be for Namhyung, as I'm sure I'm one of the first people already in that list.
Sure, you are already listed more than once.
Quoted 1 line
Quoted 1 line
probably even
event_context_switch... I'll recheck and send the patch.
This one is used by probe_wakeup_sched_switch(), so we can't simply remove it.
Quoted 7 lines
Quoted 3 lines
But what a user can do with other files? You obviously can't enable, say, ftrace/bputs, if I understand correctly this is for
trace_puts().Yeah, as
trace_printk()can turn into atrace_puts()we still want those to be read by trace-cmd. To do that, the formats for those files are exported.
Ah, indeed, thanks.
Quoted 1 line
See
kernel/trace/trace_export.candtrace_entries.h
Yeeees, I already found them. And this wasn't easy ;)
Thanks,
Oleg.