Messages in this thread | | | Date | Sat, 15 May 2010 22:43:05 -0700 | From | Arjan van de Ven <> | Subject | Re: [PATCH] x86: Export tsc related information in sysfs |
| |
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
| |