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
next prev parent 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®