All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@elte.hu, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	LKML <linux-kernel@vger.kernel.org>,
	Zhaolei <zhaolei@cn.fujitsu.com>,
	kosaki.motohiro@jp.fujitsu.com,
	Steven Rostedt <rostedt@goodmis.org>,
	fweisbec@gmail.com
Subject: Re: [PATCH 0/3] ftrace: add tracepoint for timer event
Date: Wed, 27 May 2009 13:20:04 +0800	[thread overview]
Message-ID: <4A1CCD84.2040607@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0905262320330.1762@localhost.localdomain>



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
> 
> 

      reply	other threads:[~2009-05-27  5:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22  9:43 [PATCH 0/3] ftrace: add tracepoint for timer event Xiao Guangrong
2009-05-26 21:30 ` Thomas Gleixner
2009-05-27  5:20   ` Xiao Guangrong [this message]

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=4A1CCD84.2040607@cn.fujitsu.com \
    --to=xiaoguangrong@cn.fujitsu.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.