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

[Ingo Molnar <mingo@elte.hu>]

* 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.

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?

	Ingo