Re: [PATCH] x86: Export tsc related information in sysfs

From: Arjan van de Ven
Date: Sun May 16 2010 - 01:40:30 EST

On Sat, 15 May 2010 15:32:51 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:

> > From: Arjan van de Ven [mailto:arjan@xxxxxxxxxxxxx]
> (Arjan comments reordered somewhat)
> > But friends don't let friends use rdtsc in application code.
> Um, I realize that many people have been burned by this
> many times over the years so it is a "hot stove". I also
> realize that there are many environments where using
> rdtsc is risking stepping on landmines.

> But I (we?) also
> know there are many environments now where using rdtsc is
> NOT risky at all...

I see a lot of Intel hardware.. (stuff that you likely don't see yet ;-)
and I have not yet seen a system where the kernel would be able to give
the guarantee as you describe it in your email.

If you want a sysfs variable that is always 0... go wild.

> and with the vast majority of new
> systems soon shipping with Invariant TSC and a single socket
> (and even most multiple-socket systems with non-broken
> BIOSes passing a warp test),

(the warp test is going away)

on multisocket that passes a wrap test you can still get skew over
time.. due to things like SMM, thermal throttling etc etc.

> why should past burns outlaw
> userland use of a very fast, very useful CPU feature? After
> all, CPU designers at both Intel and AMD have spent
> a great deal of design effort and transistors to FINALLY
> provide an Invariant TSC.

sadly even with all these transistors no system that I know of today
can guarantee the guarantee by the rules you state.

> > oh and.. what notification mechanism do you have to notify the
> > application that the tsc now is no longer reliable? Such conditions
> > can exist... for example due to a CPU being hotplugged, or some SMM
> > screwing around and the kernel detecting that or .. or ...
> The proposal doesn't provide a notification mechanism (though I'm
> not against it)... if the tsc can EVER become unreliable,
> tsc_reliable should be 0.

then it should be 0 always on all of todays hardware.
SMM, thermal overload, etc etc ... you name it.
Things the kernel will get notified about...

> A CPU-hotplugable system is a good example of a case where
> the kernel should expose that tsc_reliable is 0. (I've heard
> anecdotally that CPU hotplug into a QPI or Hypertransport system
> will have some other interesting challenges, so may require some
> special kernel parameters anyway.)

eh no.
hot add works just fine.

(hot remove is a very different ballgame)

> > really. Use the vsyscall. If the vsyscall does not do exactly what
> > you want, make a better vsyscall.
> If this discussion results in a better vsyscall and/or a way
> for applications to easily determine (and report loudly) that
> the system does NOT provide a good way to do a fast timestamp,
> that may be sufficient. But please propose how that will be done
> as the current software choices are inadequate and the CPU
> designers have finally fixed the problem for the vast majority
> of systems.


> I am already aware of some enterprise software
> that is doing its best to guess whether TSC is reliable by
> looking at CPU families and socket counts, but this is doomed
> to failure in userland and is something that the kernel knows
> and should now expose.

can you name said "enterprise" software by name please? We need a huge
advertisement to let people know not to trust their important data to

Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at