From: Jiri Olsa <jolsa@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
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 17:21:54 +0200 [thread overview]
Message-ID: <20100329152154.GF1715@jolsa> (raw)
In-Reply-To: <1269875347.19685.4492.camel@gandalf.stny.rr.com>
On Mon, Mar 29, 2010 at 11:09:07AM -0400, Steven Rostedt wrote:
> 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?
ok, so what you mean is:
- dont clear the max_tr and
- add function graph events.
So when the tracing_enabled and display-graph are disabled we will
get events output rather than 'unknown event' output... right?
jirka
>
> -- Steve
>
>
next prev parent reply other threads:[~2010-03-29 15:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 12:32 [PATCHv3 0/2] tracing: function graph output for preempt/irqs-off tracers 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
2010-03-29 15:21 ` Jiri Olsa [this message]
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=20100329152154.GF1715@jolsa \
--to=jolsa@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.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.