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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages