RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> >> Are you sure this will indeed be infrequent enough? On my 
> supposedly
> >> constant-TSC AMD box, I see Xen quite frequently apply small error
> >> correction factors to keep TSC from running ahead of HPET/PMTIMER.
> >
> >I'd like to hear from Keir on this, but I'd
> >guess that this would be either a bug or a
> >remnant of or inaccuracy in an old algorithm.
> >
> >Also if you could provide more information, I'd
> >like to see if I can reproduce it on my Intel
> >constant_tsc machines.
>  
> Not sure what further detail you mean - all that it is you 
> would want to
> look for are cases where error_factor is non-zero in
> local_time_calibration() (or local time getting warped forward in the
> same function; but I can only say for sure that the former does happen
> not infrequently in terms of the percentage of executions of
> local_time_calibration() - of course, that function itself doesn't run
> very frequently).

OK, I think I see the problem.

Since cs19506 "consistent_tscs" is a Xen boot parameter that
defaults to disabled.  If the boot parameter is enabled and
the boot cpu does NOT have X86_FEATURE_CONSTANT_TSC set,
consistent_tscs gets re-disabled.

For my pvrdtscp scheme to work, consistent_tscs would need to
be changed so that it defaults to enabled.

Jan, could you confirm that this solves the problem on your
constant-TSC AMD box?

Keir, is there any reason that consistent_tscs shouldn't
default to enabled?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel