Re: spinaphore conceptual draft

From: Vojtech Pavlik (vojtech_at_suse.cz)
Date: 05/30/05

  • Next message: Esben Nielsen: "Re: RT patch acceptance" 
    Date:	Mon, 30 May 2005 20:40:59 +0200
To: Kyle Moffett <mrmacman_g4@mac.com>

    On Mon, May 30, 2005 at 02:04:36PM -0400, Kyle Moffett wrote:

    > On May 30, 2005, at 13:46:35, Andi Kleen wrote:
    > >>tsc goes backwards on AMD? Under what circumstances (I'm curious,
    > >>since I'm running one...)
    > >
    > >It is not synchronized between CPUs and slowly drifts and can even run
    > >at completely different frequencies there when you use powernow! on a
    > >MP system.
    >
    > Unsynchronized is fine, we're only taking differences of short times.

    If you ask on two CPUs in a quick succession, you can get a negative
    time difference.

    > Slow drift is likewise OK too. As to the different frequencies, how
    > different are we talking about?

    1GHz vs 2GHz, for example.

    There is cpufreq, which changes the CPU clocks in large steps under the
    kernel's control, and there is spread spectrum, which wiggles them just
    a tiny bit (1-4%) back and forth (independently on different CPUs) to
    minimize EMI.

    > Also, on such a system, is there any way to determine a relative
    > frequency, even if unreliable or occasionally off?

    You can measure it. With cpufreq you have a good guess when you switch
    that the new frequency will have a certain ratio to the old one.

    > >It can be used reliably when you only do deltas on same CPU
    > >and correct for the changing frequency. However then you run
    > >into other problems, like it being quite slow on Intel.
    >
    > The deltas here are generally short, always on the same CPU, and can be
    > corrected for changing frequency, assuming that said frequency is
    > available somehow.

    The fact the deltas are on the same CPU helps. The shortness of the
    interval doesn't, since on AMD CPUs RDTSC is executed speculatively and
    out-of-order, and the order of two close RDTSC instructions isn't
    guaranteed, as far as I remember.

    > Ideally it would be some sort of CPU cycle-counter, just so I can say
    > "In between lock and unlock, the CPU did 1000 cycles", for some value
    > of "cycle".

    This may be doable if precision isn't required.

    > >I suspect any attempt to use time stamps in locks is a bad
    > >idea because of this.
    >
    > Something like this could be built only for CPUs that do support that
    > kind of cycle counter.

    RDTSC on older Intel CPUs takes something like 6 cycles. On P4's it
    takes much more, since it's decoded to a microcode MSR access. 

    -- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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/
  • Next message: Esben Nielsen: "Re: RT patch acceptance"

    Relevant Pages

    • Re: High resolution timer.
      ... It should run on Windows and Linux so there is no Win32 API. ... The first thing to use is RDTSC. ... What about multiple CPUs. ...
      (comp.lang.asm.x86)
    • Re: [PATCH] [5/20] x86: Introduce nsec_barrier()
      ... to avoid races with timer interrupts on other CPUs. ... Except for x86 it is a nop right now. ... On CPUs without SSE there is generally no RDTSC ... That's most likely wrong unless you added two barriers -- the barriers ...
      (Linux-Kernel)
    • Re: QueryPerformanceFrequency
      ... While rdtsc is one possible implementation, on some CPUs/systems the QPC needs to be implemented in a more complex manner ... I would definitely not recommend using rdtsc directly - it was quite a common practice in game programming to do this a few years back, and games which did it are experiencing serious compatibility issues recently. ... Alex Blekhman napsal: ...
      (microsoft.public.vc.language)
    • Re: [PATCH] [5/20] x86: Introduce nsec_barrier()
      ... to avoid races with timer interrupts on other CPUs. ... only tested x86, but it's a very simple change. ... On CPUs without SSE there is generally no RDTSC ...
      (Linux-Kernel)
    • Re: gettimeofday resolution seriously degraded in test9
      ... > modifies the gettimeofdayand the POSIX clock routines to ... > use rdtsc when available, a lot of problems will go away. ... sure most other modern cpus do too. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)