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

[Arjan van de Ven]

On Sat, 15 May 2010 06:29:25 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:

> > It would be better to fix them to use the vsyscalls instead.
> > Or if they can't use the vsyscalls for some reason today fix them.
> 
> The problem is from an app point-of-view there is no vsyscall.
> There are two syscalls: gettimeofday and clock_gettime.  Sometimes,
> if it gets lucky, they turn out to be very fast and sometimes
> it doesn't get lucky and they are VERY slow (resulting in a
> performance hit of 10% or more), depending on a number of factors
> completely out of the control of the app and even undetectable to the
> app.

But the point is.. in the case you get that 10% hit.... that is exactly
the case where tsc would not work either!!!
>

> If tsc_reliable is 1, the system and the kernel are guaranteeing
> to the app that nothing will change in the TSC.  In an Invariant
> TSC system that has passed Ingo's warp test (to eliminate the
> possibility of a fixed interprocessor TSC gap due to a broken BIOS
> in a multi-node NUMA system), if anything changes in the clock

just when we're trying to get rid of this constraint by allowing a per
cpu offset... (this is needed to cope with cpus not powering on at the
exact same time... including hotplug cpu etc etc)


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


really. Use the vsyscall. If the vsyscall does not do exactly what you
want, make a better vsyscall. 

But friends don't let friends use rdtsc in application code.




-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/