Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Mar 09, 2018 at 03:10:39PM +0100, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.
> 
> Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
> tolerance value of a running domU that is supposed to be migrated.
> 
> One option to avoid the TSC option is to run domUs with tsc_mode=native.
> This has the drawback that migrating a domU from a "2.3GHz" class host
> to a "2.4GHz" class host may change the rate at wich the TSC counter
> increases, the domU may not be prepared for that.
> 
> With this option the host admin can decide how a domU should behave when
> it is migrated across systems of the same class. Since there is always
> some jitter when Xen calibrates the cpu_khz value, all hosts of the same
> class will most likely have slightly different values. As a result vTSC
> emulation is unavoidable. Data collected during the incident which
> triggered this change showed a jitter of up to 200 KHz across systems of
> the same class.
> 
> A new utility is added which allows to adjust the vtsc_tolerance_khz
> value for running domUs. This is useful to avoid emulation for domUs
> that are already running and which can not be restarted.
> 
> The ordering of records sent during migration is important. The value of
> vtsc_tolerance_khz must be known by the receiving host before
> configuring TSC, because this is the place where the decision of vTSC
> emulation is made. Therefore the existing write_tsc_info function is
> modified to enforce that ordering.

There were questions on previous patches as to why this approach is
better than what we already have. Are those comments addressed?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel