From: Frederic Weisbecker <fweisbec@gmail.com>
To: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, Thomas Gleixner <tglx@linutronix.de>,
Ralf Baechle <ralf@linux-mips.org>,
Nicholas Mc Guire <der.herr@hofr.at>,
Richard Sandiford <rdsandiford@googlemail.com>,
David Daney <ddaney@caviumnetworks.com>,
Adam Nemet <anemet@caviumnetworks.com>,
Patrik Kluba <kpajko79@gmail.com>
Subject: Re: [PATCH -v5 08/11] tracing: not trace mips_timecounter_init() in MIPS
Date: Mon, 2 Nov 2009 22:43:55 +0100 [thread overview]
Message-ID: <20091102214351.GI4880@nowhere> (raw)
In-Reply-To: <1256550156.5642.148.camel@falcon>
On Mon, Oct 26, 2009 at 05:42:36PM +0800, Wu Zhangjin wrote:
> On Mon, 2009-10-26 at 01:27 +0100, Frederic Weisbecker wrote:
> > 2009/10/25 Wu Zhangjin <wuzhangjin@gmail.com>:
> > > -static inline u64 mips_timecounter_read(void)
> > > +static inline u64 notrace mips_timecounter_read(void)
> >
> >
> > You don't need to set notrace functions, unless their addresses
> > are referenced somewhere, which unfortunately might happen
> > for some functions but this is rare.
> >
>
> Okay, Will remove it.
Oops, a word has escaped from my above sentence. I wanted to say:
"You don't need to set notrace to inline functions" :)
> > Hmm yeah this is not very nice to do that in core functions because
> > of a specific arch problem.
> > At least you have __notrace_funcgraph, this is a notrace
> > that only applies if CONFIG_FUNCTION_GRAPH_TRACER
> > so that it's still traceable by the function tracer in this case.
> >
> > But I would rather see a __mips_notrace on these two core functions.
>
> What about this: __arch_notrace? If the arch need this, define it,
> otherwise, ignore it! if only graph tracer need it, define it in "#ifdef
> CONFIG_FUNCTION_GRAPH_TRACER ... #endif".
The problem is that archs may want to disable tracing on different
places.
For example mips wants to disable tracing in timecounter_read_delta,
but another arch may want to disable tracing somewhere else.
We'll then have several unrelated __arch_notrace. One that is relevant
for mips, another that is relevant for arch_foo, but all of them will
apply for all arch that have defined a __arch_notrace.
It's true that __mips_notrace is not very elegant as it looks like
a specific arch annotation intruder.
But at least that gives us a per arch filter granularity.
If only static ftrace could disappear, we could keep only dynamic
ftrace and we would then be able to filter dynamically.
But I'm not sure it's a good idea for archs integration.
next prev parent reply other threads:[~2009-11-02 21:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-25 15:16 [PATCH -v5 00/11] ftrace for MIPS Wu Zhangjin
[not found] ` <cover.1256483735.git.wuzhangjin@gmail.com>
2009-10-25 15:16 ` [PATCH -v5 01/11] tracing: convert trace_clock_local() as weak function Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 02/11] MIPS: add mips_timecounter_read() to get high precision timestamp Wu Zhangjin
2009-10-26 14:01 ` Steven Rostedt
2009-10-26 14:25 ` Wu Zhangjin
2009-10-26 14:34 ` Steven Rostedt
2009-10-26 14:42 ` Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 03/11] tracing: add MIPS specific trace_clock_local() Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 04/11] tracing: add static function tracer support for MIPS Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 05/11] tracing: enable HAVE_FUNCTION_TRACE_MCOUNT_TEST " Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 06/11] tracing: add an endian argument to scripts/recordmcount.pl Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 07/11] tracing: add dynamic function tracer support for MIPS Wu Zhangjin
2009-10-25 15:16 ` [PATCH -v5 08/11] tracing: not trace mips_timecounter_init() in MIPS Wu Zhangjin
2009-10-26 0:27 ` Frederic Weisbecker
2009-10-26 0:27 ` Frederic Weisbecker
2009-10-26 9:42 ` Wu Zhangjin
2009-11-02 21:43 ` Frederic Weisbecker [this message]
2009-11-03 1:34 ` Wu Zhangjin
2009-11-09 4:31 ` Wu Zhangjin
2009-11-09 11:53 ` Frederic Weisbecker
2009-11-09 12:08 ` Wu Zhangjin
2009-11-09 12:54 ` Steven Rostedt
2009-11-09 14:35 ` Wu Zhangjin
2009-10-25 15:17 ` [PATCH -v5 09/11] tracing: add IRQENTRY_EXIT for MIPS Wu Zhangjin
2009-10-26 0:36 ` Frederic Weisbecker
2009-10-26 7:26 ` Wu Zhangjin
2009-10-27 17:39 ` Frederic Weisbecker
2009-10-27 17:46 ` Frederic Weisbecker
2009-10-25 15:17 ` [PATCH -v5 10/11] tracing: add function graph tracer support " Wu Zhangjin
2009-10-26 15:13 ` Steven Rostedt
2009-10-26 16:11 ` Wu Zhangjin
2009-10-26 16:32 ` Steven Rostedt
2009-10-26 16:57 ` Wu Zhangjin
2009-10-26 17:11 ` Steven Rostedt
2009-10-25 15:17 ` [PATCH -v5 11/11] tracing: add dynamic function graph tracer " Wu Zhangjin
2009-10-26 1:13 ` [PATCH -v5 10/11] tracing: add function graph tracer support " Wu Zhangjin
2009-10-26 0:42 ` [PATCH -v5 00/11] ftrace " Frederic Weisbecker
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=20091102214351.GI4880@nowhere \
--to=fweisbec@gmail.com \
--cc=anemet@caviumnetworks.com \
--cc=ddaney@caviumnetworks.com \
--cc=der.herr@hofr.at \
--cc=kpajko79@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=rdsandiford@googlemail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=wuzhangjin@gmail.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;
as well as URLs for NNTP newsgroup(s).