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    [W:0.066 / U:0.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site