WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 21 Sep 2009 08:25:49 -0700 (PDT)
Cc: kurt.hackel@xxxxxxxxxx, JeremyFitzhardinge <jeremy@xxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "<Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 21 Sep 2009 08:26:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB7A7610200007800015FE6@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> 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

<Prev in Thread] Current Thread [Next in Thread>