Re: [PATCH] [15/58] i386: Rewrite sched_clock

[Mathieu Desnoyers]

* Andi Kleen (ak@xxxxxxx) wrote:
> 
> > I noticed the same thing about interrupts off when going through the
> > code.
> 
> That's only on a slow path during cpu frequency changing while the TSC is instable.
> Shouldn't be that common.
> 
> -Andi

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/