Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1327429 > unrolled thread

Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff Steven Rostedt <rostedt@goodmis.org> - 2016-02-05 03:50 +0100
    Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff Dmitry Safonov <0x7f454c46@gmail.com> - 2016-02-05 13:00 +0100
      Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff Steven Rostedt <rostedt@goodmis.org> - 2016-02-05 15:50 +0100
      Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff Steven Rostedt <rostedt@goodmis.org> - 2016-02-05 16:10 +0100
        Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff Dmitry Safonov <0x7f454c46@gmail.com> - 2016-02-05 17:00 +0100

#1327429 — Re: [RFC] trace_irqsoff: remove redundant reset per-CPU buff

On Mon, 19 Oct 2015 21:10:26 +0300
Dmitry Safonov <0x7f454c46@gmail.com> wrote:

>   There is no reason to do it twice: from commit b6f11df26fdc28
> ("trace: Call tracing_reset_online_cpus before tracer->init()")
> resetting of per-CPU buffers done before tracer->init() call.
> 
> tracer->init() calls {irqs,preempt,preemptirqs}off_tracer_init() and it
> calls __irqsoff_tracer_init(), which resets per-CPU ringbuffer second
> time.
> It's slowpath, but anyway.

Bah, I said I'd look at this and I did. But never added it to my queue.
It's not a big deal as this is the slow path but it makes sense. I knew
there was a patch from you to get but saw the TP_ARGS redefining patch
and thought that was it.

I Cc'd myself on this to make sure I see it again.

-- Steve

> 
> Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>
> ---
>  kernel/trace/trace_irqsoff.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> index 8523ea345f2b1a..4ebcb8bfaced24 100644
> --- a/kernel/trace/trace_irqsoff.c
> +++ b/kernel/trace/trace_irqsoff.c
> @@ -612,7 +612,6 @@ static int __irqsoff_tracer_init(struct trace_array *tr)
>  	irqsoff_trace = tr;
>  	/* make sure that the tracer is visible */
>  	smp_wmb();
> -	tracing_reset_online_cpus(&tr->trace_buffer);
>  
>  	ftrace_init_array_ops(tr, irqsoff_tracer_call);
>  

[toc] | [next] | [standalone]

#1327623

2016-02-05 5:40 GMT+03:00 Steven Rostedt <rostedt@goodmis.org>:
> On Mon, 19 Oct 2015 21:10:26 +0300
> Dmitry Safonov <0x7f454c46@gmail.com> wrote:
>
>>   There is no reason to do it twice: from commit b6f11df26fdc28
>> ("trace: Call tracing_reset_online_cpus before tracer->init()")
>> resetting of per-CPU buffers done before tracer->init() call.
>>
>> tracer->init() calls {irqs,preempt,preemptirqs}off_tracer_init() and it
>> calls __irqsoff_tracer_init(), which resets per-CPU ringbuffer second
>> time.
>> It's slowpath, but anyway.
>
> Bah, I said I'd look at this and I did. But never added it to my queue.
> It's not a big deal as this is the slow path but it makes sense. I knew
> there was a patch from you to get but saw the TP_ARGS redefining patch
> and thought that was it.

Thanks, Steve!
Yeah, I know it may take time to get to unimportant patches
that are also mostly cleanups.
Don't worry, please, take a glance when you'll have time on these
small also not important cleanings (I'm fine if you'll drop them all):
https://lkml.org/lkml/2015/11/20/290
https://lkml.org/lkml/2015/11/20/291
https://lkml.org/lkml/2015/10/30/580

>
> I Cc'd myself on this to make sure I see it again.
>
> -- Steve




-- 
Regards,
Safonov Dmitry.

[toc] | [prev] | [next] | [standalone]

#1327816

On Fri, 5 Feb 2016 14:52:53 +0300
Dmitry Safonov <0x7f454c46@gmail.com> wrote:

> 2016-02-05 5:40 GMT+03:00 Steven Rostedt <rostedt@goodmis.org>:
> > On Mon, 19 Oct 2015 21:10:26 +0300
> > Dmitry Safonov <0x7f454c46@gmail.com> wrote:
> >  
> >>   There is no reason to do it twice: from commit b6f11df26fdc28
> >> ("trace: Call tracing_reset_online_cpus before tracer->init()")
> >> resetting of per-CPU buffers done before tracer->init() call.
> >>
> >> tracer->init() calls {irqs,preempt,preemptirqs}off_tracer_init() and it
> >> calls __irqsoff_tracer_init(), which resets per-CPU ringbuffer second
> >> time.
> >> It's slowpath, but anyway.  
> >
> > Bah, I said I'd look at this and I did. But never added it to my queue.
> > It's not a big deal as this is the slow path but it makes sense. I knew
> > there was a patch from you to get but saw the TP_ARGS redefining patch
> > and thought that was it.  
> 
> Thanks, Steve!
> Yeah, I know it may take time to get to unimportant patches
> that are also mostly cleanups.
> Don't worry, please, take a glance when you'll have time on these
> small also not important cleanings (I'm fine if you'll drop them all):
> https://lkml.org/lkml/2015/11/20/290
> https://lkml.org/lkml/2015/11/20/291
> https://lkml.org/lkml/2015/10/30/580

I'm slowing going through my INBOX (doing clean up to see what I
missed). I'm currently at 11/10. I marked your 10/30 one already as a
"go back and look at later".

-- Steve

[toc] | [prev] | [next] | [standalone]

#1327826

On Fri, 5 Feb 2016 14:52:53 +0300
Dmitry Safonov <0x7f454c46@gmail.com> wrote:


> Thanks, Steve!
> Yeah, I know it may take time to get to unimportant patches
> that are also mostly cleanups.
>

Also, FYI, even if you do an RFC, include "PATCH" in the brackets as
well. I usually have "[RFC][PATCH]". Because when I'm looking for
patches in my inbox, I will filter for PATCH. If a patch is out there
without that in the subject, it is much more likely to be missed (and
most likely will).

-- Steve

[toc] | [prev] | [next] | [standalone]

#1327860

2016-02-05 18:04 GMT+03:00 Steven Rostedt <rostedt@goodmis.org>:

> Also, FYI, even if you do an RFC, include "PATCH" in the brackets as
> well. I usually have "[RFC][PATCH]". Because when I'm looking for
> patches in my inbox, I will filter for PATCH. If a patch is out there
> without that in the subject, it is much more likely to be missed (and
> most likely will).

Will do.
And I added RFC mostly because, I didn't see the reason for reseting
second time, but if it has been (I wasn't sure), I wanted to add a comment,
why.

-- 
Regards,
Safonov Dmitry.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web