similar to: How to disable kvm_steal_time feature

27 нояб. 2015 г. 14:15 пользователь "Martin Kletzander" <mkletzan@redhat.com> написал: > > On Fri, Nov 20, 2015 at 04:31:56PM +0100, Piotr Rybicki wrote: >> >> Hi. >> >> I would like to workaround a bug, when after live-migration of KVM >> guest, there is a 100% steal time shown in guest. >> >> I've read, that disabling

2015-11-27 16:57 GMT+03:00 Martin Kletzander <mkletzan@redhat.com>: > I don't think we report that in domain stats, but top/virt-top could > help with that. Ok libvirt can't get this value, but does it possible if i know cpu stats of domain and host info (i don't know which =)) determine for specific domain does it possible have steal time or not? -- Vasiliy Tolstov,

On Fri, Nov 20, 2015 at 04:31:56PM +0100, Piotr Rybicki wrote: >Hi. > >I would like to workaround a bug, when after live-migration of KVM >guest, there is a 100% steal time shown in guest. > >I've read, that disabling 'kvm_steal_time' feature should workarund >this bug, but i can't find a way to disable it in libvirt's domain xml >file. > There is no

On Fri, Nov 27, 2015 at 04:25:55PM +0300, Vasiliy Tolstov wrote: >27 нояб. 2015 г. 14:15 пользователь "Martin Kletzander" <mkletzan@redhat.com> >написал: >> >> On Fri, Nov 20, 2015 at 04:31:56PM +0100, Piotr Rybicki wrote: >>> >>> Hi. >>> >>> I would like to workaround a bug, when after live-migration of KVM >>> guest,

2016-10-19 06:20-0400, Pan Xinhui: > This is to fix some lock holder preemption issues. Some other locks > implementation do a spin loop before acquiring the lock itself. > Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It > takes the cpu as parameter and return true if the cpu is preempted. Then > kernel can break the spin loops upon on the retval of

2016-10-19 06:20-0400, Pan Xinhui: > This is to fix some lock holder preemption issues. Some other locks > implementation do a spin loop before acquiring the lock itself. > Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It > takes the cpu as parameter and return true if the cpu is preempted. Then > kernel can break the spin loops upon on the retval of

On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote: > 2016-07-06 20:28 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: > > Hmm, you're right. We can use bit 0 of struct kvm_steal_time's flags to > > indicate that pad[0] is a "VCPU preempted" field; if pad[0] is 1, the > > VCPU has been scheduled out since the last time the guest reset the

On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote: > 2016-07-06 20:28 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: > > Hmm, you're right. We can use bit 0 of struct kvm_steal_time's flags to > > indicate that pad[0] is a "VCPU preempted" field; if pad[0] is 1, the > > VCPU has been scheduled out since the last time the guest reset the

2016-10-24 16:39+0200, Paolo Bonzini: > On 19/10/2016 19:24, Radim Kr?m?? wrote: >>> > + if (vcpu->arch.st.msr_val & KVM_MSR_ENABLED) >>> > + if (kvm_read_guest_cached(vcpu->kvm, &vcpu->arch.st.stime, >>> > + &vcpu->arch.st.steal, >>> > + sizeof(struct kvm_steal_time)) == 0) { >>> > +

2016-10-24 16:39+0200, Paolo Bonzini: > On 19/10/2016 19:24, Radim Kr?m?? wrote: >>> > + if (vcpu->arch.st.msr_val & KVM_MSR_ENABLED) >>> > + if (kvm_read_guest_cached(vcpu->kvm, &vcpu->arch.st.stime, >>> > + &vcpu->arch.st.steal, >>> > + sizeof(struct kvm_steal_time)) == 0) { >>> > +

On Wed, Feb 15, 2017 at 04:37:50PM -0500, Waiman Long wrote: > +/* > + * Hand-optimize version for x86-64 to avoid 8 64-bit register saving and > + * restoring to/from the stack. It is assumed that the preempted value > + * is at an offset of 16 from the beginning of the kvm_steal_time structure > + * which is verified by the BUILD_BUG_ON() macro below. > + */ > +#define

On Wed, Feb 15, 2017 at 04:37:50PM -0500, Waiman Long wrote: > +/* > + * Hand-optimize version for x86-64 to avoid 8 64-bit register saving and > + * restoring to/from the stack. It is assumed that the preempted value > + * is at an offset of 16 from the beginning of the kvm_steal_time structure > + * which is verified by the BUILD_BUG_ON() macro below. > + */ > +#define

On 02/10/2017 11:19 AM, Peter Zijlstra wrote: > On Fri, Feb 10, 2017 at 10:43:09AM -0500, Waiman Long wrote: >> It was found when running fio sequential write test with a XFS ramdisk >> on a VM running on a 2-socket x86-64 system, the %CPU times as reported >> by perf were as follows: >> >> 69.75% 0.59% fio [k] down_write >> 69.15% 0.01% fio [k]

On 02/10/2017 11:19 AM, Peter Zijlstra wrote: > On Fri, Feb 10, 2017 at 10:43:09AM -0500, Waiman Long wrote: >> It was found when running fio sequential write test with a XFS ramdisk >> on a VM running on a 2-socket x86-64 system, the %CPU times as reported >> by perf were as follows: >> >> 69.75% 0.59% fio [k] down_write >> 69.15% 0.01% fio [k]

From: Pan Xinhui > Sent: 20 October 2016 22:28 > Commit ("x86, kvm: support vcpu preempted check") add one field "__u8 > preempted" into struct kvm_steal_time. This field tells if one vcpu is > running or not. > > It is zero if 1) some old KVM deos not support this filed. 2) the vcpu is > preempted. Other values means the vcpu has been preempted. >

From: Pan Xinhui > Sent: 20 October 2016 22:28 > Commit ("x86, kvm: support vcpu preempted check") add one field "__u8 > preempted" into struct kvm_steal_time. This field tells if one vcpu is > running or not. > > It is zero if 1) some old KVM deos not support this filed. 2) the vcpu is > preempted. Other values means the vcpu has been preempted. >

On 06/07/2016 14:08, Wanpeng Li wrote: > 2016-07-06 18:44 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: >> >> >> On 06/07/2016 08:52, Peter Zijlstra wrote: >>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >>>> change fomr v1: >>>> a simplier definition of default vcpu_is_preempted >>>> skip mahcine

On 06/07/2016 14:08, Wanpeng Li wrote: > 2016-07-06 18:44 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: >> >> >> On 06/07/2016 08:52, Peter Zijlstra wrote: >>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >>>> change fomr v1: >>>> a simplier definition of default vcpu_is_preempted >>>> skip mahcine

Hello, On Wed, Nov 02, 2016 at 05:08:35AM -0400, Pan Xinhui wrote: > Support the vcpu_is_preempted() functionality under KVM. This will > enhance lock performance on overcommitted hosts (more runnable vcpus > than physical cpus in the system) as doing busy waits for preempted > vcpus will hurt system performance far worse than early yielding. > > Use one field of struct

Hello, On Wed, Nov 02, 2016 at 05:08:35AM -0400, Pan Xinhui wrote: > Support the vcpu_is_preempted() functionality under KVM. This will > enhance lock performance on overcommitted hosts (more runnable vcpus > than physical cpus in the system) as doing busy waits for preempted > vcpus will hurt system performance far worse than early yielding. > > Use one field of struct