[PATCH 0/3] ftrace: add tracepoint for timer event

[PATCH 0/3] ftrace: add tracepoint for timer event

[Xiao Guangrong]

Hi,

We can know timer's whole lifecycle as init/start/expire/cancel by
these tracepoints. 

Following tracepoints are introduced as ingo's suggestion in
	http://marc.info/?l=linux-kernel&m=123791899529128&w=2

for timer:
trace_timer_init()
trace_timer_start()
trace_timer_expire()
trace_timer_cancel()

for hrtimer:
trace_hrtimer_init()
trace_hrtimer_start()
trace_hrtimer_expire()
trace_hrtimer_cancel()

for itimer:
itimer_start()
itimer_expire()
itimer_cancel()

Example ftrace output:
for timer:
           <...>-2998  [000] 63501.542376: timer_init: timer=e0b374e0
           <...>-2998  [000] 63501.542424: timer_start: timer=e0b374e0 func=test_timerfuc expires=4294941565 cpu=0
	  <idle>-0     [000] 63514.508219: timer_expire: timer=e0b374e0 func=test_timerfuc
          <idle>-0     [000] 63514.508222: timer_cancel: timer=e0b374e0 func=test_timerfuc

for hrtimer:
           <...>-3628  [001] 64228.304772: hrtimer_init: timer=e0b404cc clockid=CLOCK_REALTIME mode=HRTIMER_MODE_ABS
           <...>-3628  [001] 64228.304793: hrtimer_start: timer=e0b404cc func=test_hrtime expires=1242920654000000000 ns softexpires=1242920654000000000 ns
     ksoftirqd/1-7     [001] 64228.304858: hrtimer_expire: timer=e0b404cc func=test_hrtime
     ksoftirqd/1-7     [001] 64228.304860: hrtimer_cancel: timer=e0b404cc func=test_hrtime

for itimer:
           <...>-4183  [001] 66533.730163: itimer_start: task=main which=0 it_value=13000000000 it_interval=0
          <idle>-0     [001] 66546.698154: itimer_expire: task=main which=0
           <...>-4183  [000] 66546.698533: itimer_cancel: task=main which=0

We already have debugobject in timer to init/activate/deactivate/free,
but it can't be covered function of there tracepoints, because:
1: We can't get timer's lifecycle information in userspace by debugobject,
   it is necessary for system engineer to investigate system trouble caused
   by using timer.
2: We can't get information of whole lifecycle of timer by debugobject, 
   for example, deactivation of a timer.
3: There are many different tracing code in many kernel subsystem as blktrace,
   debugobject, and tracepoint is designed as generic way to unify these
   tracing way.

include/trace/events/timer.h |  249 +++++++++++++++++++++++++++++++++++++++++++
 kernel/hrtimer.c             |    5
 kernel/itimer.c              |   17 ++
 kernel/posix-cpu-timers.c    |    3
 kernel/timer.c               |    9 +
 5 files changed, 279 insertions(+), 4 deletions(-)

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

[Thomas Gleixner]

On Fri, 22 May 2009, Xiao Guangrong wrote:
> We already have debugobject in timer to init/activate/deactivate/free,
> but it can't be covered function of there tracepoints, because:
> 1: We can't get timer's lifecycle information in userspace by debugobject,
>    it is necessary for system engineer to investigate system trouble caused
>    by using timer.
> 2: We can't get information of whole lifecycle of timer by debugobject, 
>    for example, deactivation of a timer.
> 3: There are many different tracing code in many kernel subsystem as
>    blktrace, debugobject, and tracepoint is designed as generic way
>    to unify these tracing way.

No. You can not unify debugobject into tracepoints. debugobjects is a
totally different beast. It's main purpose is to prevent undebugable
system crashes which we have seen several times e.g: freeing of an
active timer, reinitializing of an active timer ...

Dealing with these problems is not covered by tracepoints by any
means. The trace point does not prevent the system crash which happens
2 seconds after the fact that an active timer is kfree'd, debugobject
does and it points you to the exact place where the shit happens.

I'm not opposed to add tracepoints to the timer code at all. In fact I
appreciate that, but your idea of substituting debugobjects with
tracing is just plain wrong.

It's the other way round. tracing can reuse the existing debugobject
hooks to insert trace points, but it can not replace the functionality
at all.

Thanks,

	tglx

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

[Xiao Guangrong]

Thomas Gleixner wrote:
> On Fri, 22 May 2009, Xiao Guangrong wrote:
>> We already have debugobject in timer to init/activate/deactivate/free,
>> but it can't be covered function of there tracepoints, because:
>> 1: We can't get timer's lifecycle information in userspace by debugobject,
>>    it is necessary for system engineer to investigate system trouble caused
>>    by using timer.
>> 2: We can't get information of whole lifecycle of timer by debugobject, 
>>    for example, deactivation of a timer.
>> 3: There are many different tracing code in many kernel subsystem as
>>    blktrace, debugobject, and tracepoint is designed as generic way
>>    to unify these tracing way.
> 
> No. You can not unify debugobject into tracepoints. debugobjects is a
> totally different beast. It's main purpose is to prevent undebugable
> system crashes which we have seen several times e.g: freeing of an
> active timer, reinitializing of an active timer ...
> 
> Dealing with these problems is not covered by tracepoints by any
> means. The trace point does not prevent the system crash which happens
> 2 seconds after the fact that an active timer is kfree'd, debugobject
> does and it points you to the exact place where the shit happens.
> 
> I'm not opposed to add tracepoints to the timer code at all. In fact I
> appreciate that, but your idea of substituting debugobjects with
> tracing is just plain wrong.
> 
> It's the other way round. tracing can reuse the existing debugobject
> hooks to insert trace points, but it can not replace the functionality
> at all.
> 

Hello tglx:
Thanks for you review!

Totally agree.
Actually I do know the difference between debugobject and tracepoint. Sorry
for making you misunderstand what I said for my pool English.

Thanks,
Xiao Guangrong

> 	tglx
> 
>