[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090123110037.GI15188@elte.hu>
Date: Fri, 23 Jan 2009 12:00:37 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Frédéric Weisbecker <fweisbec@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 v2] tracing/function-graph-tracer: various fixes
and features
* Frédéric Weisbecker <fweisbec@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists