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

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> 
> On Mon, 17 May 2010, Dan Magenheimer wrote:
> >
> > OK, so let's invert the sense of the sysfs file and call it (for now)
> > "tsc_detected_as_UNreliable".  Then anytime the kernel detects
> > a failed warp test (or any other suspicious condition), it changes
> > the bit from 0 to 1 effectively saying "if you are using rdtsc
> > against our recommendation, we told you that it might go bad and
> > it has, so consider yourself warned that some of the timestamps
> > you've taken since the last time you've checked this flag
> > may be b*rked"
> >
> > IMHO, addressing the issue directly and clearly documenting it
> > (instead of trying to hide the dirty laundry in the kernel)
> > will result in far better education of systems programmers
> > and far fewer end user problems. Which raises another good analogy:
> >
> > You are telling teenagers to abstain and I am proposing that we
> > instead encourage them to use a condom.
> 
> Wrong. A vsyscall _is_ the protection which you want them to pull over
> the rdtsc.
> 
> You are basically telling them: Go ahead, but keep in mind to look for
> that well hidden tag behind the left earlobe which might change
> suddenly from "no disease" to "infectous".

OK, well ignoring the metaphor, it's clear we disagree on a point
that neither one of us can prove: You think your decision to avoid
sharing kernel information will stop system programmers from using
rdtsc, and I think some are going to use rdtsc anyway and blame
Linux when something eventually and silently breaks.

Given that I'm not going to win this argument even by pointing
to examples, let's move forward with your solution.  Can you say
more about your vget_tsc_raw() directions?  Or at least describe
the API if there is anything special?  I'm getting beaten on for
an answer *today*, they say (and I quote from an email today)
they "have been using vsyscalls for a while and still have a
performance headache", and rdtsc looks awfully tempting, even
if it is not 100% perfect.  So what can I give them as an
alternative?

(And, yes, I understand this is not your problem, but I do worry
that it is perceived as *Linux's* problem.  And as we all have
painfully learned in our careers, it's almost impossible to
beat back a perception by presenting a set of byzantine facts
that only a handful of people in the world truly understand.)

Thanks!
Dan