Re: [PATCH 0/3] Improve TSC as a clocksource under VMware
From: Alok Kataria
Date: Tue Oct 21 2008 - 15:10:47 EST
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
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.
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/