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] RE: [PATCH] clocksource=tsc

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH] clocksource=tsc
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 17 Jul 2008 17:47:58 -0600
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 17 Jul 2008 16:48:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D9566@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjkZ5sqwfzsRK8bRLOogZ+uDOy+agBK8Gg8AAvqplAAE4lzEACU67AQ
> Boot option is good enough for now, but finally I guess you may
> need some type of dynamic clocksource switch mechanism,
> just like what Linux does today. User may be not sure of the
> specific platform. Some features may affect TSC stabilitity, e.g.
> Px may have freq change and Cx may have TSC stop on some
> platform. On those path a mark_tsc_unstable step is required
> to switch current clocksource to other available platfrom timer
> on the fly. So besides the boot option, Xen itself needs to code
> such condition checks for TSC stability. :-)

Yes, agreed.

I think there are "good tsc" machines where TSC will never
skew, "bad tsc" machines where the skew is apparent at
boot, and "grey tsc" machines where there is skew but
the skew happens to be small at boot but may grow
to be bad post-boot possibly due to Px/Cx.  In order
to handle all of these here's the algorithm that I'm
thinking of:

1) Use processor bits (borrowing code from a recent Linux
   version) to determine whether a system is likely to
   be "good tsc" or "bad tsc".  Set the tsc_invariant
   global variable accordingly.
2) When synchronize_tsc_bp()/ap() dynamically evaluates
   skew, change tsc_invariant if appropriate.
3) If tsc_invariant is set when clocksource is being
   selected, tsc should be the default clocksource,
   unless overridden by clocksource= on the boot line
   OR a new boot parameter "notsc".
4) Write a pair of routines equivalent to
   synchronize_tsc_bp/ap() but which
   just returns whether or not TSCs are sync'ed.  Call this
   routine whenever a processor exits from Cx/Px and
   also on a decaying counter, e.g. 1 second after boot,
   then 2 seconds after that, then 4 seconds after that,
   etc.  If skew is detected, change the clocksource
   to the next best and printk the change.
5) I don't know if it is currently "safe" to change
   clocksources after the initial selection in
   init_platform_timer() so this may take some work.

Comments?

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