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

[Arjan van de Ven <arjan@infradead.org>]

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

> > From: Arjan van de Ven [mailto:arjan@infradead.org]
> (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. 

*cough*

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



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org