lkml.org 
[lkml]   [2010]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateSat, 15 May 2010 22:43:05 -0700
FromArjan van de Ven <>
SubjectRe: [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


\
 
 \ /
  Last update: 2010-05-16 07:43    [from the cache]
©2003-2010