From: Steven Rostedt <rostedt@goodmis.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCHv3 0/2] tracing: function graph output for preempt/irqs-off tracers
Date: Mon, 29 Mar 2010 11:09:07 -0400 [thread overview]
Message-ID: <1269875347.19685.4492.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20100329111701.GC1715@jolsa>
On Mon, 2010-03-29 at 13:17 +0200, Jiri Olsa wrote:
> > # echo 0 > /debug/tracing/tracing_enabled
> > # echo 0 > /debug/tracing/option/display-graph
> > # cat /debug/tracing/trace
> >
> > # tracer: irqsoff
> > irqbalan-2672 0d..2. 55us+: Unknown type 13
> > irqbalan-2672 0d.h2. 62us+: Unknown type 13
>
> I forgot the max_tr buffer is actually the one displayed,
> so it needs reset as well when the display-graph option
> is switched on/off.
No! That breaks the rules. It should still show the contents of the
buffer even if we disable the trace or option.
> > I think you can still do the "event" part, without effecting the way the
> > function graph outputs normally. I would not have given up on that
> > method. You don't need to worry about it processing other events,
> > because when you register it to write as an event, it will only be
> > called when a function graph event was found. It will not be processing
> > other events. Only when the tracer itself overrides the default writing
> > will it do so.
>
> The events would be called only for TRACE_GRAPH_RET, TRACE_GRAPH_ENT entries and
> not for others, thats right.
>
> However it's the graph ouput code that outputs other events' text
> within "/*" and "*/".
>
> So using the event way, all other events would be printed as normal
> events(standard lines not alligned) with the standard header...
> not like comments, as they are in the function_graph tracer.
>
> I thought it'd be good for graph output to stay the same in irqsoff
> tracer as in function_graph tracer.. if that is not the concern
> the event way would be probably nicer :)
It is, but you missed my point.
>
> I'm sending updated patchset with above 2 fixies right away,
> I can do/resend the event way later if needed.
What I'm saying is that we should have _both_! The event way (when the
option is disabled) and the current way when it is not. That is, if the
option is enabled, then the function graph can report all the data the
way it was. If the option is disabled, don't reset it, but have an
"event" print of the trace as well.
Understand what I'm trying to ask?
-- Steve
next prev parent reply other threads:[~2010-03-29 15:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 12:32 Jiri Olsa
2010-03-26 12:32 ` [PATCHv3 1/2] tracing: graph output support for irqsoff tracer Jiri Olsa
2010-03-26 12:32 ` [PATCHv3 2/2] tracing: graph output support for preemptirqsoff/preemptoff tracers Jiri Olsa
2010-03-26 14:53 ` [PATCHv3 0/2] tracing: function graph output for preempt/irqs-off tracers Steven Rostedt
2010-03-29 11:17 ` Jiri Olsa
2010-03-29 15:09 ` Steven Rostedt [this message]
2010-03-29 15:21 ` Jiri Olsa
2010-03-29 15:41 ` Steven Rostedt
2010-03-31 7:37 ` Jiri Olsa
2010-03-31 8:01 ` Frederic Weisbecker
2010-03-31 10:36 ` Jiri Olsa
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=1269875347.19685.4492.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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®