[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] New utility: 'trace'
On 11/17/2010 05:02 AM, Peter Zijlstra wrote:
> On Wed, 2010-11-17 at 13:53 +0100, Frederic Weisbecker wrote:
>> On Wed, Nov 17, 2010 at 12:35:50PM +0100, Peter Zijlstra wrote:
>>> On Wed, 2010-11-17 at 09:30 +0100, Ingo Molnar wrote:
>>>>> For example I'm currently working with dozens of trace_printk() and I would be
>>>>> very happy to turn some of them off half of the time.
>>>> I guess we could try such a patch. If you send a prototype i'd be interested in
>>>> testing it out.
>>> I don't see the point, the kernel shouldn't contain any trace_printk()s
>>> to begin with..
>> It's oriented toward developers. Those who use dozens of tracepoints in
>> their tree because they are debugging something or developing a new feature,
>> they might to deactivate/reactivate some of these independant points.
>> This can also apply to dynamic_printk of course.
>> Well, the very first and main point is to standardize trace_printk into
>> a trace event so that it gets usable by perf tools. I have been asked many
>> times "how to use trace_printk() with perf?".
> Thing is, since its these dev who add the trace_printk()s to begin with,
> I don't see the point in splitting them out, if you didn't want them why
> did you add them to begin with?!

What I understood from Frederic's email was that during a debug session
it is sometimes helpful to be able to enable and disable the
trace_printk's. This makes sense as it reduces the number of kernel
build/reboot cycles. However, I would think most of that could be
accomplished with some judicious message tagging and post-processing to
filter out the unwanted trace_printk's. The only exception might be when
the trace_printk's add enough overhead to mask a timing related bug. In
this case, I'd probably be tempted to remove the stubs anyway.

Darren Hart
Yocto Linux Kernel

 \ /
  Last update: 2010-11-17 19:29    [W:0.104 / U:14.432 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site