From: Thomas Gleixner <tglx@linutronix.de>
To: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Cc: Zhaolei <zhaolei@cn.fujitsu.com>,
mingo@elte.hu, LKML <linux-kernel@vger.kernel.org>,
kosaki.motohiro@jp.fujitsu.com,
Steven Rostedt <rostedt@goodmis.org>,
fweisbec@gmail.com
Subject: Re: [PATCH 1/3] ftrace: add tracepoint for timer
Date: Thu, 4 Jun 2009 10:44:38 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.00.0906041017220.3419@localhost.localdomain> (raw)
In-Reply-To: <4A275DDC.6020507@cn.fujitsu.com>
On Thu, 4 Jun 2009, Xiao Guangrong wrote:
> > void debug_and_trace_timer_activate(....)
> > {
> > debug_timer_activate(...);
> > trace_timer_activate(...);
> > }
> >
> > in the timer code:
> >
> > - debug_timer_activate(...);
> > + debug_and_trace_timer_activate(...);
> >
> > So this does not change the order of functions at all, but it avoids
> > sprinkling the real code with tons of extra crap.
> >
>
> See below code:
>
> static inline int
> __mod_timer(......)
> {
> ......
> ......
>
- debug_timer_activate(timer);
+ debug_and_trace_timer_activate(timer, expires);
Does the trick nicely
> In addition, do you agree my humble opinion about not put __init_timer() and
> debug_timer_init() together? (can be found at:
No, I do not agree at all. I still see no value in those extra trace
points. As I showed you above you can hide all in extra arguments to a
combined debug_trace_xxx() function.
> http://marc.info/?l=linux-kernel&m=124399744614127&w=2)
>> But TRACE_EVENT not only be used in ftrace but also be used in
>> other probe module. Maybe detailed information of timer is
>> requisite in other probe funtion. In this case, we must put
>> trace_timer_init() after __init_timer().
Please stop this handwaving about potential use cases. I still have
not seen a single technical argument which explains the benefit of
those extra trace points. If we follow your "maybe its needed" logic
then we have to add yet another dozen of tracepoints into the same
functions to gather all possible states which might be there.
Tracing is important but it needs to be done unintrusive to the code
and you have to apply common sense which information is really
valuable and necessary. Gathering random crap just because it might be
necessary at some point is useless.
Get your gear together, sit down and think hard about which
information a tracer or a probe needs to have to give us a useful
insight into a particular object or function.
As long as there is no technical convincing argument that the gathered
information is really useful I'm not going to apply any of those
patches to the code I maintain.
Thanks,
tglx
next prev parent reply other threads:[~2009-06-04 8:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-22 9:53 Xiao Guangrong
2009-05-26 21:40 ` Thomas Gleixner
2009-05-27 7:36 ` Xiao Guangrong
2009-05-27 10:10 ` Thomas Gleixner
2009-05-29 2:00 ` Zhaolei
2009-05-29 9:55 ` Thomas Gleixner
2009-06-01 9:08 ` Zhaolei
2009-06-03 2:52 ` Xiao Guangrong
2009-06-03 16:39 ` Thomas Gleixner
2009-06-04 5:38 ` Xiao Guangrong
2009-06-04 8:44 ` Thomas Gleixner [this message]
2009-06-10 9:42 ` Xiao Guangrong
2009-06-10 10:58 ` Thomas Gleixner
2009-06-03 2:50 ` Xiao Guangrong
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=alpine.LFD.2.00.0906041017220.3419@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=xiaoguangrong@cn.fujitsu.com \
--cc=zhaolei@cn.fujitsu.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®