lkml.org 
[lkml]   [2009]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes and features
On Fri, Jan 23, 2009 at 12:00:37PM +0100, Ingo Molnar wrote:
>
> * Frédéric Weisbecker <fweisbec@gmail.com> wrote:
>
> > > Still needs a solution - if we do cross-CPU traces we want to have a
> > > global trace clock with 'seemless' transition between CPUs.
> >
> > 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...
>
> using ktime_get() is indeed out of question - GTOD callpaths are too
> complex (and also too slow).
>
> I'd not change anything in the current logic, but i was thinking of a new
> trace_option, which can be set optionally. If that trace option is set
> then this bit of ring_buffer_time_stamp():
>
> time = sched_clock() << DEBUG_SHIFT;
>
> gets turned into:
>
> time = cpu_clock(cpu) << DEBUG_SHIFT;
>
> This way we default to sched_clock(), but also gain some 'global'
> properties if the trace_option is set.


Ok, yeah that's a good idea.


> Furthermore, another trace_option could introduce a third 'strongly
> ordered' trace-clock variant, which would use cmpxchg and per cpu
> timestamps, something like this:
>
> atomic64_t curr_time;
>
> DEFINE_PER_CPU(u64, prev_cpu_time);
> ...
>
> retry:
> prev_cpu_time = per_cpu(prev_cpu_time, cpu);
> cpu_time = sched_clock();
> old_time = atomic64_read(&curr_time);
>
> delta = cpu_time - prev_cpu_time;
> if (unlikely((s64)delta <= 0))
> delta = 1;
>
> new_time = old_time + delta;
>
> if (atomic64_cmpxchg(&curr_time, old_time, new_time) != new_time)
> goto repeat;
>
> time = new_time << DEBUG_SHIFT;
>
> This would be a monotonic, global clock wrapped around sched_clock(). It
> uses a cmpxchg to achieve it, but we have to use global ordering anyway.
>
> It would still be _much_ faster than any GTOD clocksource we have.
>
> Hm?
>

And that would be even more faster that cpu_clock().

But why implement both? Wouldn't the above be more faster while playing the same thing
than cpu_clock()

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-01-24 17:05    [W:2.493 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site