From: Zhaolei <zhaolei@cn.fujitsu.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Xiao Guangrong <xiaoguangrong@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: Re: Re: [PATCH 1/3] ftrace: add tracepoint for timer
Date: Mon, 01 Jun 2009 17:08:34 +0800 [thread overview]
Message-ID: <4A239A92.60708@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0905290935030.3397@localhost.localdomain>
Thomas Gleixner wrote:
> On Fri, 29 May 2009, Zhaolei wrote:
>> But, for trace_timer_start() in __mod_timer(), we need to put it after
>> timer->* changed.
>
> Why ?
Hello, Thomas
Thanks for your review.
Please see my explain below.
>
>>> + TP_fast_assign(
>>> + __entry->timer = timer;
>>> + __entry->function = timer->function;
>>> + __entry->expires = timer->expires;
>>> + __entry->cpu = cpu;
>
> Again, neither timer nor function nor expires will change when the
> timer is added, right ?
>
Sorry for my poor English.
I don't means that internal_add_timer() will change timer->*.
My meaning is:
timer->expires = expires; *
internal_add_timer(base, timer);
*: timer->expires is changed here, so trace_timer_start() need to called below
this line. If we call debug_timer_activate() and trace_timer_start() together,
we need to move debug_timer_activate() to place below this line too.
> The only unknown at this point is cpu. See below.
>
>> Nevertheless, it don't means we need separate trace_timer_start() and
>> debug_timer_activate(), because we can put move debug_timer_activate() below,
>> as:
>> - debug_timer_activate(timer);
>> ...
>> timer->expires = expires;
>> internal_add_timer(base, timer);
>> + debug_timer_activate(timer);
>
> No, you can not call it with the base->lock held.
>
>> + trace_timer_start(timer, smp_processor_id());
>
> Also using smp_processor_id() here is wrong. We do not necessarily add
> the timer to the current CPUs timer wheel. See the code which selects
> the timer base. So this information is rather useless, because the
> tracer knows anyway on which CPU we are running.
>
> Unfortunately we do not have an easy way to figure out to which CPU
> the base belongs (except if it's the base of the current CPU). There
> is not much we can do about that. But OTOH, this is not a problem
> because we see when the timer expires on which CPU it was enqueued. So
> scrapping the cpu entry in the trace completely is not a big loss.
Indeed.
We can remove smp_processor_id() from trace_timer_start()'s argument.
Xiao Guangrong, author of this patch is in vacation these days, and will come
back recently.
Maybe we want to hear his opinion about this fix.
Thanks
Zhaolei
next prev parent reply other threads:[~2009-06-01 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-22 9:53 [PATCH 1/3] ftrace: add tracepoint for timer 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 [this message]
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
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=4A239A92.60708@cn.fujitsu.com \
--to=zhaolei@cn.fujitsu.com \
--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=tglx@linutronix.de \
--cc=xiaoguangrong@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