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: Thu, 13 Nov 2008 21:06:24 +0100 From: "Frédéric Weisbecker" <fweisbec@...il.com> To: "Ingo Molnar" <mingo@...e.hu> Cc: "Steven Rostedt" <rostedt@...dmis.org>, "Linux Kernel" <linux-kernel@...r.kernel.org>, "Peter Zijlstra" <a.p.zijlstra@...llo.nl> Subject: Re: [PATCH 1/2] tracing/function-return-tracer: Make the function return tracer lockless 2008/11/13 Ingo Molnar <mingo@...e.hu>: > you are right - it needs a bit more logic. > > I think the simplest would be something like this: > > atomic64_t global_clock = INIT_ATOMIC64(0); > > u64 global_time() > { > u64 now, delta, now_global, prev_global; > > do { > prev_global = atomic64_read(&global_clock); > now = cpu_clock(raw_smp_processor_id()); > > if ((s64)(now - prev_global) < 0) { > now = prev_global; > break; > } > } while (atomic64_cmpxchg(&global_clock, > prev_global, now) != prev_global); > > return now; > } > > This is the simplest way of implementing monotonic time: we only allow > global_clock to go forwards. If all cpu_clock()s are perfectly in > sync, we've got no problem: then "now - prev_global" will never be > negative and we can return the local clock as the latest global time. > > But if one of the CPU clocks is "behind", the function returns the > latest global time up until the local clock catches up. Time wont be > allowed to jump around by going back. If the clock is behind for a > long time, then we get a lot of timestamps with the same value - Ok! I understand now this approach. So, if global ordering flag is set, we return this kind of protected value, and on the opposite, we return the normal cpu_clock() local value. > Would that work? [ Would you be interested in sending patches? :-) ] Yes :-) > that > will be very visible in the trace and we'll then work in improving the > cpu_clock() implementation. > > So i think we could start with this simplest approach, and see how > often we get the same timestamp for a long time (indication of the > clocks being not perfectly in sync). Ok, good idea. Thanks for the explanations! -- 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