Re: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes and features

From: Frédéric Weisbecker
Date: Fri Jan 23 2009 - 05:36:50 EST


2009/1/23 Ingo Molnar <mingo@xxxxxxx>:
>
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
>
>>
>> This patch brings various bugfixes:
>>
>> _ Drop the first irrelevant task switch on the very beginning of a trace.
>> _ Drop the OVERHEAD word from the headers, the DURATION word is sufficient and will not
>> overlap other columns.
>> _ Make the headers fit well their respective columns whatever the selected options.
>
>> About features, one can now disable the duration (this will hide the
>> overhead too for convenient reasons and because on doesn't need overhead
>> if it hasn't the duration
>
> very nice! I've applied this to tip/tracing/function-graph-tracer, thanks
> Frederic!
>
> this:
>
>> I guess no one needs the nanosec precision here, the main goal is to
>> find when happened the events on a cpu when the trace switches from one
>> cpu to another.
>>
>> ie:
>>
>> 274.874760 | 1) 0.676 us | _spin_unlock();
>> 274.874762 | 1) 0.609 us | native_load_sp0();
>> 274.874763 | 1) 0.602 us | native_load_tls();
>> 274.878739 | 0) 0.722 us | }
>> 274.878740 | 0) 0.714 us | native_pmd_val();
>> 274.878741 | 0) 0.730 us | native_pmd_val();
>>
>> Here there is a 4000 usecs difference when we switch the cpu.
>
> Still needs a solution - if we do cross-CPU traces we want to have a
> global trace clock with 'seemless' transition between CPUs.
>
> Ingo
>

So it doesn't only need a monotonic clock. It needs a global
consistent clock like ktime for example?
Unfortunately this one uses seq_locks and would add some drawbacks
like verifying if the traced
function doesn't hold the write seq_lock and it will bring some more
ftrace recursion...
--
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/