[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
> > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |