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

[Thomas Gleixner]

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.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/