Re: [PATCH 1/3] ftrace: add tracepoint for timer

[Thomas Gleixner <tglx@linutronix.de>]

Xiao,

On Wed, 10 Jun 2009, Xiao Guangrong wrote:
> Those tracepoints are wanted and useful:
> 1) We can detect a timer's delay if jiffies info is added, like this:
> 
> 	XXX: timer_start: timer=e0b374e0 func=test_timerfuc expires=4294941565
> 	XXX: timer_expire: timer=e0b374e0 func=test_timerfuc jiffies=4294941567
>    We expect the timer expires at 4294941565, actually the timer expires at
>    4294941567, so it is delayed by 2 jiffies.

You can achive the same thing by storing (expires - jiffies) when you
trace the timer start. Then you can calc the delta from the trace
timestamps, but I have no strong opinion about that.

> 2) We can monitor the lifecycle and behaviors of a timer, for
>    example, when monitoring dirty writeback timer, I found reading
>    /proc/sys/vm/dirty_writeback_centisecs will reset the timer:

 
> 3) We are developing "flight-record" using crash. It can read out the ring
>    buffer from the dump file, and let us know what was happening before
>    kernel panic, so we may find the cause of the panic. This requires
>    well-defined tracepoints in different kernel subsystems, especially some
>    core subsystems, timer is surely one of them.

I'm not arguing that tracepoints are not useful, but you can achieve
all the things above by combining them in an unintrusive way to the
existing debug points.

This results in the minimum noise of debug/trace insertions into the
code, which keeps it readable and maintainable. That's all I want.

Thanks,

	tglx