From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Zhaolei <zhaolei@cn.fujitsu.com>,
kosaki.motohiro@jp.fujitsu.com,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Anton Blanchard <anton@samba.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/4] ftrace: add tracepoint for hrtimer
Date: Wed, 22 Jul 2009 17:36:54 +0800 [thread overview]
Message-ID: <4A66DDB6.4000700@cn.fujitsu.com> (raw)
In-Reply-To: <1248091771.15751.8578.camel@twins>
Peter Zijlstra wrote:
> Ah, but you don't get those anyway, I'd argue the whole expire thing is
> broken. The only expiry you get is the hardware interrupt firing.
> Anything after that is a free-for-all.
>
> Look at that loop in hrtimer_interrupt(), with your tracepoint, they'd
> all expire at the same time, regardless of how long previous callback's
> took to complete.
>
> Also, the whole loop can be re-tried, updating 'now' expiring a whole
> new set of timers without expiry event.
>
Yes, the expire time that got by _expire() is incorrect and thanks for
your point out.
> The best you can get is a tracepoint when the hrtimer interrupt happens,
> and the IRQ tracepoint already give you that.
>
I'm trying to fix it address your comment, but meet some problems,
the time of ftrace output can't solve everything, because:
1: the time unit of ftrace output is microsecond, but hrtimer's unit
is nanosecond, it's not exact for us
2: the time of ftrace ouput is the time after system boot, but we need
xtime and wall_to_monotonic to calculate latency of hrtimer,
for example:
insmod-3821 [001] 3192.239335: hrtimer_start: timer=d08a1480 expires=1245162841000000000 ns
<idle>-0 [001] 3201.506127: hrtimer_expire: timer=d08a1480
we expect the timer expire at 1245162841000000000 ns, this is base on
xtime, but we don't know the interval running that we are expect hrtimer
to run if we don't know the xtime at hrtimer_start or hrtimer_expire.
But it's hard for hrtime's TRACE_EVENT to get xtime and wall_to_monotonic
since it's a fast patch, if we have to do this, the code maybe like below:
TRACE_EVENT(hrtimer_expire,
......
TP_STRUCT__entry(
__field( void *, timer )
__field( s64, now )
__field( s64, offset )
),
TP_fast_assign(
__entry->timer = timer;
__entry->now = ktime_get().tv64;
__entry->wtom = timespec_to_ktime(wall_to_monotonic).tv64;
),
TP_printk("timer=%p now=%llu ns wtom=%llu", __entry->timer,
(unsigned long long)__entry->now, (unsigned long long)__entry->wtom)
);
We need cooperate with trace_hrtimer_init() to get hrtimer's clockid.
That make trace_hrtimer_expire() slow.
Though the original patch get expire time not exactly, but It harm system's
performance very little.
Thanks,
Xiao
> So I really don't see the use-case for this _expiry tracepoint, its just
> too ill-defined.
>
> The _entry and _exit ones I can agree with, this stuff just doesn't make
> any sense.
>
>
next prev parent reply other threads:[~2009-07-22 9:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-17 10:11 [PATCH v3 0/4] ftrace: add tracepoint for timer event Xiao Guangrong
2009-07-17 10:14 ` [PATCH v3 1/4] tracing/events: Add timer and high res timer tracepoints Xiao Guangrong
2009-07-17 10:16 ` [PATCH v3 2/4] ftrace: add tracepoint for timer Xiao Guangrong
2009-07-17 10:18 ` [PATCH v3 3/4] ftrace: add tracepoint for hrtimer Xiao Guangrong
2009-07-17 10:50 ` Peter Zijlstra
2009-07-20 7:25 ` Xiao Guangrong
2009-07-20 12:09 ` Peter Zijlstra
2009-07-22 9:36 ` Xiao Guangrong [this message]
2009-07-22 10:13 ` Peter Zijlstra
2009-07-22 15:36 ` Mathieu Desnoyers
2009-07-23 10:01 ` Xiao Guangrong
2009-07-23 10:07 ` Peter Zijlstra
2009-07-24 9:40 ` Xiao Guangrong
2009-07-24 11:11 ` Peter Zijlstra
2009-07-17 10:20 ` [PATCH v3 4/4] ftrace: add tracepoint for itimer 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=4A66DDB6.4000700@cn.fujitsu.com \
--to=xiaoguangrong@cn.fujitsu.com \
--cc=anton@samba.org \
--cc=fweisbec@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--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