RE: [Xen-devel] [PATCH] TSC scaling for live migration between platforms with different TSC frequecies

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > 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