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

From: Thomas Gleixner
Date: Sun May 16 2010 - 05:21:43 EST

On Sat, 15 May 2010, Arjan van de Ven wrote:
> 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.

Nah, there are systems which will have it set to 1:

Dig out your good old Pentium-I box and enjoy.

> > > 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...

What we could expose is an estimate about the performance of
gettimeofday/clock_gettime. The kernel has all the information to do
that, but this still does not solve the notification problem when we
need to switch to a different clock source.


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