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

[Thomas Gleixner]

On Sun, 16 May 2010, Dan Magenheimer wrote:

> > > > From: Thomas Gleixner [mailto:tglx@xxxxxxxxxxxxx]
> > > > What we can talk about is a vget_tsc_raw() interface along with a
> > 
> > What I have in mind and what I'm working on for quite a while is going
> > to work on both bare metal and VMs w/o hidden slowness.
> 
> Well, if this can be done today/soon and is fast enough
> (say <2x the cycles of a rdtsc), I am very interested and

Are you going to measure that with rdtsc() ? :)

> "won't let my friends use rdtsc" :-)  Anything I can do
> to help?

Yes, stop trying to convince me that rdtsc in apps is a good idea. :)

> It sounds as if you are saying that "the kernel is allowed
> to use a rope because if it accidentally gets the rope
> around its neck, it has a knife to ensure it doesn't hang
> itself" BUT "the app isn't allowed to use a rope because
> it might hang itself and we'll be damned if we loan
> our knife to an app because, well... because it doesn't
> need a knife because we said it shouldn't use the rope".
> 
> I think you can understand why this isn't a very satisfying
> explanation.

What I understand is that you want us to give out the rope only and
when things go wrong let us kernel developers deal with the bugreports
about the missing knife.

Please understand that once we expose that tsc_reliable information we
are responsible for its correctness. People will use it whether the
enterprise entity who wants this feature has qualified that particular
piece of hardware or not. And while the support of that enity refuses
to help on non qualified hardware (your own words), we'll end up with
the mess which was created to help that very entity.

I think you understand that I have no intention to put a ticking time
bomb into the code I'm responsible for. I really have better things to
do than shooting myself in the foot.

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/