lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 24 Jan 2009 17:02:45 +0100 From: Frederic Weisbecker <fweisbec@...il.com> To: Ingo Molnar <mingo@...e.hu> 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 On Fri, Jan 23, 2009 at 12:00:37PM +0100, Ingo Molnar wrote: > > * 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. 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@...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