Messages in this thread | | | Date | Fri, 23 Jan 2009 11:36:38 +0100 | Subject | Re: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes and features | From | Frédéric Weisbecker <> |
| |
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...
| |