Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
>>> On 09.04.18 at 16:55, wrote: > Am Mon, 09 Apr 2018 08:19:53 -0600 > schrieb "Jan Beulich" : > >> Is there any guarantee that old hypervisors will send this field as zero >> (rather than some random value)? If so, I think this should be said >> explicitly in the commit message, together with the fact that you >> re-use padding fields. > > I have to double check, but I'm sure the whole size of the struct is > initialized with zero. The commit message already has "Existing padding > fields are reused to store vtsc_khz_tolerance as u16." It's that sentence that I've referred to - it talks about padding, but doesn't make clear that this padding is zero at all times. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
Am Mon, 09 Apr 2018 08:19:53 -0600 schrieb "Jan Beulich" : > Is there any guarantee that old hypervisors will send this field as zero > (rather than some random value)? If so, I think this should be said > explicitly in the commit message, together with the fact that you > re-use padding fields. I have to double check, but I'm sure the whole size of the struct is initialized with zero. The commit message already has "Existing padding fields are reused to store vtsc_khz_tolerance as u16." Thanks, Olaf pgpesO4uraFI2.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
>>> On 01.04.18 at 22:29, wrote: > @@ -34,7 +35,8 @@ int handle_tsc_info(struct xc_sr_context *ctx, struct > xc_sr_record *rec) > } > > if ( xc_domain_set_tsc_info(xch, ctx->domid, tsc->mode, > -tsc->nsec, tsc->khz, tsc->incarnation) ) > +tsc->nsec, tsc->khz, tsc->vtsc_tolerance, > +tsc->incarnation) ) Is there any guarantee that old hypervisors will send this field as zero (rather than some random value)? If so, I think this should be said explicitly in the commit message, together with the fact that you re-use padding fields. Hypervisor side provisionally (upon Andrew finding his prior concerns addressed) Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation
On Sun, Apr 01, 2018 at 10:29:58PM +0200, 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. > > 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 the new 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. > > Existing padding fields are reused to store vtsc_khz_tolerance as u16. > > Signed-off-by: Olaf Hering Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
