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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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

Just checking... this is in 10 seconds and each processor is
"ticking" (and possibly a system-wide timer tick as well),
so this is ~350 rdtsc/sec/processor, correct?

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

I believe PV is no more safe (and the proposed patch doesn't
work for PV).

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

Yes indeed.  It would be nice if some x86 wizard could
spin up a best case for this and if someone with good
hardware measurement tools could compare current vs best
(as well as measure true instruction frequency as apps
might be rdtsc'ing directly).

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