Re: [PATCH 0/3] Improve TSC as a clocksource under VMware

[Alok Kataria <akataria@vmware.com>]

On Tue, 2008-10-21 at 11:15 -0700, Andi Kleen wrote:
> > FWIU from the code, even if  cpu A's TSC is just 1 tick behind that of
> > cpu B, we increment the nr_wraps value.
> > And the code expects that there are no wraps in TSC throughout the
> > 20msec measurement window.
> > So IMO its fairly easy to fail this test.
> 
> Ok I think it would be better to enlarge the margin then to fix your
> issue.
> 

Yeah, i thought about that, but given the different kinds of native
hardware that we have i think coming up with values that would be safe
for all the cases would be difficult. And given that nobody has
complained about this on native until now, i would prefer not to change
the status quo. Apart from that, even on VMware virtualized environment
there can different configurations where this margin keeps on varying,
under different scenarios, f.e. under overcommitment and all. So i don't
think that changing threshold values maybe safe for all cases. 

I think going with ignoring this check for specific systems is the best
way to go further. I am open to either having a check for 
CONSTANT_TSC or a new flag tsc_reliable (similar to my patch).

I hope you also agree with the CONSTANT_TSC check.

Thanks,
Alok


> -Andi