[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Jun 18, 2009 at 01:27:23PM -0700, Dan Magenheimer wrote:

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

# dtrace -n 'fbt::tsc_gethrtime:entry /cpu == 0/ { @ = sum(1); }' -c "sleep 10"
dtrace: description 'fbt::tsc_gethrtime:entry ' matched 1 probe
dtrace: pid 29708 has exited

            27798

This is on a basically idle 8-way system. (The other CPUs are less busy.)

http://blogs.sun.com/eschrock/entry/microstate_accounting_in_solaris_10

> that data centers running Solaris guests must segregate sets of
> their machines by clock rate and disallow migrations
> between the sets?

Certainly for Solaris HVM that has to be the case until we make it use PV time
(presuming that is safe, which I'm not sure offhand).

> 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

At the end of the day, though, only testing will tell us for sure.

regards
john

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.