Hrm, I don't see why you can get away without disabling interrupts in
the fast path:
+unsigned long long tsc_sched_clock(void)
+{
+ unsigned long long r;
+ struct sc_data *sc = &get_cpu_var(sc_data);
+
+ if (unlikely(sc->unstable)) {
+ r = (jiffies_64 - sc->sync_base) * (1000000000 / HZ);
+ r += sc->ns_base;
+ /*
+ * last_val is used to avoid non monotonity on a
+ * stable->unstable transition. Make sure the time
+ * never goes to before the last value returned by the
+ * TSC clock.
+ */
+ while (r <= sc->last_val) {
+ rmb();
+ r = sc->last_val + 1;
+ rmb();
+ }
+ sc->last_val = r;
Here, slow path, we update last_val (64 bits value). Must be protected.
+ } else {
+ rdtscll(r);
+ r = __cycles_2_ns(sc, r);
+ sc->last_val = r;
Here, fast path, we update last_val too so it is ready to be read when
the tsc will become unstable.
If we don't disable interrupts around its update, we could have: (LSB vs
MSB update order is arbitrary)
update sc->last_val 32MSB
interrupt comes
update sc->last_val 32MSB
update sc->last_val 32LSB
iret
update sc->last_val 32LSB
So if, after this, we run tsc_sched_clock() with an unstable TSC, we
read a last_val containing the interrupt's MSB and the last_val LSB. It
can particularity hurt if we are around a 32 bits overflow, because time
could "jump" forward of about 1.43 seconds on a 3 GHz system.
So I guess we need synchronization on the fast path, and therefore using
cmpxchg_local on x86_64 and cmpxchg64_local on i386 makes sense.
Mathieu
+ }
+
+ put_cpu_var(sc_data);
+
+ return r;
+}
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
