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

["Frédéric Weisbecker" <fweisbec@gmail.com>]

2009/1/23 Ingo Molnar <mingo@elte.hu>:
>
> * Frederic Weisbecker <fweisbec@gmail.com> 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...