[PATCH] ftrace: kill global_start_up

[PATCH] ftrace: kill global_start_up

[Oleg Nesterov]

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.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 kernel/trace/ftrace.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 5b372e3..4586f8d 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -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;
 
-- 
1.5.5.1

Re: [PATCH] ftrace: kill global_start_up

[Steven Rostedt]

On Sun, 20 Jul 2014 17:18:14 +0200
Oleg Nesterov <oleg@redhat.com> wrote:

> 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.
> 

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

> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
>  kernel/trace/ftrace.c |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 5b372e3..4586f8d 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -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;
>  

Re: [PATCH] ftrace: kill global_start_up

[Steven Rostedt]

On Mon, 21 Jul 2014 09:47:06 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Sun, 20 Jul 2014 17:18:14 +0200
> Oleg Nesterov <oleg@redhat.com> wrote:
> 
> > 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.
> > 
> 
> 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/1402584972-17824-1-git-send-email-namhyung@kernel.org

-- Steve

Re: [PATCH] ftrace: kill global_start_up

[Oleg Nesterov]

On 07/21, Steven Rostedt wrote:
>
> On Mon, 21 Jul 2014 09:47:06 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Sun, 20 Jul 2014 17:18:14 +0200
> > Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > > 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.
> > >
> >
> > 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/1402584972-17824-1-git-send-email-namhyung@kernel.org

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.

Re: [PATCH] ftrace: kill global_start_up

[Steven Rostedt]

On Wed, 23 Jul 2014 20:29:11 +0200
Oleg Nesterov <oleg@redhat.com> wrote:


> > Nevermind, seems that Namhyung Kim beat you to it (and it's already in
> > my for-next branch).
> >
> > http://lkml.kernel.org/r/1402584972-17824-1-git-send-email-namhyung@kernel.org
> 
> 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.

> 
> 
> 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

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!

> 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.

> 
> 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


> Confused...

Aren't we all?

-- Steve

Re: [PATCH] ftrace: kill global_start_up

[Oleg Nesterov]

On 07/23, Steven Rostedt wrote:
>
> On Wed, 23 Jul 2014 20:29:11 +0200
> Oleg Nesterov <oleg@redhat.com> 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.

> > 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.

> > 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.

Ah, indeed, thanks.

> See kernel/trace/trace_export.c and trace_entries.h

Yeeees, I already found them. And this wasn't easy ;)

Thanks,

Oleg.