All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Frank A. Cancio Bello" <frank@generalsoftwareinc.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, saiprakash.ranjan@codeaurora.org,
	nachukannan@gmail.com
Subject: Re: [PATCH] tracing: Resets the trace buffer after a snapshot
Date: Fri, 3 Jan 2020 17:37:11 -0500	[thread overview]
Message-ID: <20200103223711.GC189259@google.com> (raw)
In-Reply-To: <20200103114001.2c118ab1@gandalf.local.home>

On Fri, Jan 03, 2020 at 11:40:01AM -0500, Steven Rostedt wrote:
> On Tue, 31 Dec 2019 03:58:22 -0500
> "Frank A. Cancio Bello" <frank@generalsoftwareinc.com> wrote:
> 
> > Currently, when a snapshot is taken the trace_buffer and the
> > max_buffer are swapped. After this swap, the "new" trace_buffer is
> > not reset. This produces an odd behavior: after a snapshot is taken
> > the previous snapshot entries become available to the next reader of
> > the trace_buffer as far as the reading occurs before the buffer is
> > refilled with new entries by a writer.
> 
> I consider this a feature not a bug ;-)
> 
> Anyway, this behavior should be determined by an option. Care to create
> one? (reset_on_snapshot?) I would keep the default behavior the same,
> but document this a bit better.

I relate to what Steve said as well. It is not strictly a bug per-se. An
option to do this would be nice but I am doubting a user will really turn on
such option (or even know an option exists) ;-). I would say leave it in the
current state unless some usecase is disrupted by the current behavior..

thanks!

 - Joel


> 
> Thanks!
> 
> -- Steve
> 
> > 
> > This patch resets the trace buffer after a snapshot is taken.
> > 
> > Signed-off-by: Frank A. Cancio Bello <frank@generalsoftwareinc.com>
> > ---
> > 
> > The following commands illustrate this odd behavior:
> > 
> > # cd /sys/kernel/debug/tracing
> > # echo nop > current_tracer
> > # echo 1 > tracing_on
> > # echo m1 > trace_marker
> > # echo 1 > snapshot
> > # echo m2 > trace_marker
> > # echo 1 > snapshot
> > # cat trace
> > # tracer: nop
> > #
> > # entries-in-buffer/entries-written: 1/1   #P:2
> > #
> > #                              _-----=> irqs-off
> > #                             / _----=> need-resched
> > #                            | / _---=> hardirq/softirq
> > #                            || / _--=> preempt-depth
> > #                            ||| /     delay
> > #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> > #              | |       |   ||||       |         |
> >             bash-550   [000] ....    50.479755: tracing_mark_write: m1
> > 
> > 
> >  kernel/trace/trace.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index ddb7e7f5fe8d..58373b5ae0cf 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -6867,10 +6867,13 @@ tracing_snapshot_write(struct file *filp, const char __user *ubuf, size_t cnt,
> >  			break;
> >  		local_irq_disable();
> >  		/* Now, we're going to swap */
> > -		if (iter->cpu_file == RING_BUFFER_ALL_CPUS)
> > +		if (iter->cpu_file == RING_BUFFER_ALL_CPUS) {
> >  			update_max_tr(tr, current, smp_processor_id(), NULL);
> > -		else
> > +			tracing_reset_online_cpus(&tr->trace_buffer);
> > +		} else {
> >  			update_max_tr_single(tr, current, iter->cpu_file);
> > +			tracing_reset_cpu(&tr->trace_buffer, iter->cpu_file);
> > +		}
> >  		local_irq_enable();
> >  		break;
> >  	default:
> 

  reply	other threads:[~2020-01-03 22:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31  8:58 [PATCH] tracing: Resets the trace buffer after a snapshot Frank A. Cancio Bello
2020-01-03 16:40 ` Steven Rostedt
2020-01-03 22:37   ` Joel Fernandes [this message]
2020-01-05 10:31     ` Frank A. Cancio Bello
2020-01-06 17:41       ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200103223711.GC189259@google.com \
    --to=joel@joelfernandes.org \
    --cc=frank@generalsoftwareinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nachukannan@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.