lkml.org 
[lkml]   [2007]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [15/58] i386: Rewrite sched_clock
* Andi Kleen (ak@suse.de) 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-20 16:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site