mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Jason Wessel <jason.wessel@windriver.com>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	kgdb-bugreport@lists.sourceforge.net,
	Brian Norris <briannorris@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] tracing: kdb: Allow ftdump to skip all but the last few lines
Date: Fri, 15 Mar 2019 16:12:03 -0400	[thread overview]
Message-ID: <20190315161203.25dc2a0c@gandalf.local.home> (raw)
In-Reply-To: <CAD=FV=WUnmMxKZrH-Jfz-VocieOu-Cfsi1aLpB8G5FnLM+_W_w@mail.gmail.com>

On Fri, 15 Mar 2019 12:55:31 -0700
Doug Anderson <dianders@chromium.org> wrote:

> >
> > Actually, you can add a function in trace.c that exposes
> > get_total_entries:
> >
> > unsigned long trace_total_entries(struct trace_array *tr)
> > {
> >         unsigned long total, entries;
> >
> >         if (!tr)
> >                 tr = &global_trace;
> >
> >         get_total_entries(tr->trace_buffer, &total, &entries);
> >
> >         return entries;
> > }
> >
> > and then do:
> >                 cnt = trace_total_entries(NULL);  
> 
> OK.  I guess I'll need to figure out how to add an argument to limit
> it to just one CPU too since the kdb command allows you to specify a
> single CPU or all CPUs.  I think the best way would mean adding an
> argument to get_total_entries().  ...or I can just change the kdb
> command to not allow specifying a CPU?  Which do you prefer?  I
> personally haven't ever used the feature to just print the ftrace
> buffer for a certain CPU so I'd be OK removing it.

I would make a get_total_entries_cpu() that contains the guts of
get_total_entries() which then calls get_total_entries_cpu()

static void
get_total_entries(struct trace_buffer *buf,
		  unsigned long *total, unsigned long *entries)
{
	unsigned long t, e;
	int cpu;

	*total = 0;
	*entries = 0;

	for_each_tracing_cpu(cpu)
		get_total_entries_cpu(buf, &t, &e, cpu);
		*total += t;
		*entries += e;
	}
}
	
> 
> 
> > Don't modify ftrace_dump_buf()  
> 
> I still kinda prefer modifying ftrace_dump_buf() just because it's
> pretty important that the "count" we come up with match pretty exactly
> the count that ftrace_dump_buf() will come up with.  My worry probably
> comes from my lack of experience with the internals of ftrace but, for
> instance, I see things like "tr->trace_flags &=
> ~TRACE_ITER_SYM_USEROBJ" in ftrace_dump_buf() and I worry that it will
> affect the count.  ...but if you tell me that I need not worry about
> things like that then I won't.  :-)

Hmm, actually your method still wont work, because you are only
counting entries not lines. The stack dumps are considered a single
line but will print multiple lines.

Not only that, perhaps you should break apart ftrace_dump_buf(),
because calling it twice (or doing what I suggested), wont stop tracing
in between, and the size of the buffer might change between the two
calls.

You need to move out:

	for_each_tracing_cpu(cpu) {
		atomic_inc(&per_cpu_ptr(iter.trace_buffer->data, cpu)->disabled);
	}


and

	for_each_tracing_cpu(cpu) {
		atomic_dec(&per_cpu_ptr(iter.trace_buffer->data, cpu)->disabled);
	}

to disable tracing while you do this.

The get_total_entries() is the faster approach to get the count, but in
either case, the count should end up the same.

-- Steve

  reply	other threads:[~2019-03-15 20:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 17:45 Douglas Anderson
2019-03-15 18:41 ` Steven Rostedt
2019-03-15 19:55   ` Doug Anderson
2019-03-15 20:12     ` Steven Rostedt [this message]
2019-03-15 20:54       ` Doug Anderson
2019-03-15 21:08         ` Steven Rostedt
2019-03-15 21:28           ` Doug Anderson
2019-03-15 21:33             ` 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=20190315161203.25dc2a0c@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=briannorris@chromium.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=jason.wessel@windriver.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®