All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dan Magenheimer" <dan.magenheimer@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	"Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>
Cc: Dave Winchell <dwinchell@virtualiron.com>
Subject: RE: RE: [PATCH] clocksource=tsc
Date: Thu, 17 Jul 2008 17:47:58 -0600	[thread overview]
Message-ID: <20080717174758687.00000001344@djm-pc> (raw)
In-Reply-To: <D470B4E54465E3469E2ABBC5AFAC390F024D9566@pdsmsx412.ccr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

> 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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2008-07-17 23:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-12 21:38 [PATCH] clocksource=tsc Dan Magenheimer
2008-07-13  3:59 ` Dan Magenheimer
2008-07-14  9:24 ` Keir Fraser
2008-07-14 17:59   ` Dan Magenheimer
2008-07-15  0:35     ` Tian, Kevin
2008-07-17 23:47       ` Dan Magenheimer [this message]
2008-07-15 13:05     ` Keir Fraser
2008-07-15 14:44       ` Dan Magenheimer
2008-07-15 15:08         ` Keir Fraser
2008-07-15 15:46           ` Dan Magenheimer
2008-07-15 16:04             ` Dan Magenheimer
2008-07-16  1:15               ` Dan Magenheimer
2008-07-16  4:11                 ` Dan Magenheimer
2008-07-16 12:43                   ` Dan Magenheimer
2008-07-16 12:49                     ` Keir Fraser
2008-07-16 13:43                       ` Dan Magenheimer
2008-07-16 15:42                         ` Dan Magenheimer
2008-07-16 19:32                           ` Keir Fraser
2008-07-17 23:05                       ` Dan Magenheimer
2008-07-18  7:24                         ` Keir Fraser
2008-07-18 11:01                           ` Keir Fraser
2008-07-18 11:10                             ` Keir Fraser
2008-07-18 14:19                               ` Dan Magenheimer
2008-07-18 14:29                                 ` Keir Fraser
2008-07-18 14:56                                   ` Dan Magenheimer
2008-07-18 15:00                                     ` Keir Fraser
2008-07-18 16:51                                       ` Dan Magenheimer
2008-07-18 19:28                                         ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080717174758687.00000001344@djm-pc \
    --to=dan.magenheimer@oracle.com \
    --cc=dwinchell@virtualiron.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.