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] [PATCH] TSC scaling for live migration between platforms

To: John Levon <levon@xxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] TSC scaling for live migration between platforms with different TSC frequecies
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 18 Jun 2009 13:27:23 -0700 (PDT)
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Thu, 18 Jun 2009 13:29:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090618164535.GA30082@xxxxxxxxxxxxxxxxx>
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
> > Other apps (and/or the OS kernel) may use TSC to
> > approximate the passage of time, and for these apps
> > (and gettimeofday in the Linux kernel), this TSC scaling
> > patch is a must.  Unfortunately, both kinds of apps could
> > be running simultaneously on the same guest.  And
> > in either case, RDTSC frequency may be quite high.
> 
> Certainly Solaris relies on the TSC for time-keeping, and uses it very
> heavily. To the extent that I doubt it's even feasible to migrate to a
> machine where scaling needs to be done, and such a migration should be
> refused, since it would essentially kill the guest.

Hmmm... any numbers?  Certainly Solaris isn't reading TSC much
more than a thousand times per second, is it?  Are you suggesting
that data centers running Solaris guests must segregate sets of
their machines by clock rate and disallow migrations
between the sets?
 
> > question is:  If it is important to ALWAYS emulate RDTSC,
> > can the Xen code be written to handle RDTSC emulation
> > much faster?  If it could be made fast enough, the
> 
> I'd be amazed if this were possible.

If it were PA-RISC or Itanium, I'd take on the challenge,
but I just don't know x86 well enough.  Are traps really
THAT expensive on x86?  (If max(TSC/sec/processor)~=1000 and
cycles/emulation~=5000, total degradation would be
less than 1%.  (Sounds high, but if the alternative is
clocks going haywire, seems a small price to pay. And
I expect the frequency and cost estimates (1000 and 5000)
are probably too high.)

Also, might turning RDTSC emulation on be much faster
on newer processors than old?

Dan

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

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