[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts
>>> On 24.05.17 at 17:33, <konrad.wilk@xxxxxxxxxx> wrote: > On Wed, May 24, 2017 at 05:25:03PM +0200, Olaf Hering wrote: >> On Wed, May 24, Konrad Rzeszutek Wilk wrote: >> >> > How can that be determined? As in how can the guest (domU) be within >> > the range? Is there some way to determine that? Is there some >> > matrix of the various OS-es that can tolerate this? >> >> Just cycle through all dom0s and look for the cpu_khz values: >> # xl dmesg | grep -w MHz >> (XEN) Detected 2494.018 MHz processor. >> >> What I have seen are ranges up to 200khz, even if /proc/cpuinfo says >> "2.50GHz" . Some dom0s calibrated themselves to exactly 2500.000 MHz, >> they do not need a tolerance. >> >> The expected frequency of a given domU can be seen in 'dump softtsc >> stats' (s). How various guest kernels deal with the slightly different >> frequency, no idea. > > Right, so that answers how one would find the values (which I think > should be in the docs?). > > But it does not help customers to figure out if this is OK for them? > > As in, how can customers be assured that 1% jitter is OK for their > kernel? That time won't go backwards? > > Is there some form of tests that they can run to verify and test > that this is safe? Or perhaps this is something that is based on the kernel > versions? Like 4.11 are safe, but 3.18 is not? Well, no, what jitter may be acceptable depends on the applications running inside the guest. I.e. you can only know for yourself or ask the application vendor(s). I think such an option, if we really want to have it, would need to be prominently documented as unsupported - after all we can't help it if people use it and then find their applications break. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |