search for: kvm_steal_time

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. Tried in <cpu> section: <feature policy='disable' name='kvm_steal_time'/> but that doesn't work. Also, couldn't find any related information in l...

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 bit. > > The guest can use an xchg to test-and-clear it. The bit can be > > accessed at any time, inde...

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 bit. > > The guest can use an xchg to test-and-clear it. The bit can be > > accessed at any time, inde...

...аписал: > > 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 support for that in libvirt. Either we must addit ad a > feature (patches welcome), but if that's there just for a workaround,...

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 support for that in libvirt. Either we must addit ad a feature (patches welcome), but if that's there just for a workaround, I would suggest chasing the...

...v 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 support for that in libvirt. Either we must addit ad a >> feature (patches welcome), but if that's there...

...gt;> Paolo, could you help out with an (x86) KVM interface for this? >> >> If it's just for spin loops, you can check if the version field in the >> steal time structure has changed. > > Steal time will not be updated until ahead of next vmentry except > wrmsr MSR_KVM_STEAL_TIME. So it can't represent it is preempted > currently, right? 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 bit...

...gt;> Paolo, could you help out with an (x86) KVM interface for this? >> >> If it's just for spin loops, you can check if the version field in the >> steal time structure has changed. > > Steal time will not be updated until ahead of next vmentry except > wrmsr MSR_KVM_STEAL_TIME. So it can't represent it is preempted > currently, right? 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 bit...

...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 vcpu_is_preempted. > > As kernel has used this interface, So lets support it. > > We use one field of struct kvm_steal_time to indicate that if one vcpu > is running or not. > > unix benchmark result: > host: kernel 4.8.1, i5-4570, 4 cpus > guest: kernel 4.8.1, 8 vcpus > > test-case after-patch before-patch > Execl Throughput | 18307.9 lps | 11701.6 lps >...

...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 vcpu_is_preempted. > > As kernel has used this interface, So lets support it. > > We use one field of struct kvm_steal_time to indicate that if one vcpu > is running or not. > > unix benchmark result: > host: kernel 4.8.1, i5-4570, 4 cpus > guest: kernel 4.8.1, 8 vcpus > > test-case after-patch before-patch > Execl Throughput | 18307.9 lps | 11701.6 lps >...

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 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) { >>> > + vcpu->arch.st.steal.preempted = 1; >>> > + kvm_write_guest_cached(vcpu->kvm, &vcpu->arch.st.stime, >>> > + &vcpu->arch.st.steal, >>> > + sizeof(struct kvm_steal_time)); >>> > + } >>...

...> 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) { >>> > + vcpu->arch.st.steal.preempted = 1; >>> > + kvm_write_guest_cached(vcpu->kvm, &vcpu->arch.st.stime, >>> > + &vcpu->arch.st.steal, >>> > + sizeof(struct kvm_steal_time)); >>> > + } >>...

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 kvm_steal_time to indicate that if one vcpu is running or not. unix benchmark result: host: kernel 4.8.1, i5-4570, 4 cpus guest: kernel 4.8.1, 8 vcpus test-case after-patch before-patch Execl Throughput | 18307.9 lps | 11701.6 lps File Copy 1024...

On Fri, Nov 27, 2015 at 05:47:16PM +0300, Vasiliy Tolstov wrote: >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 =))

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 PREEMPTED_OFFSET 16 As per Andrew's suggestion, the 'right' way is something like so. --- asm-offsets_64.c | 11 +++++++++++ kvm.c | 14 ++++---------- 2 files changed, 15 i...

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 PREEMPTED_OFFSET 16 As per Andrew's suggestion, the 'right' way is something like so. --- asm-offsets_64.c | 11 +++++++++++ kvm.c | 14 ++++---------- 2 files changed, 15 i...

v3->v4: - Fix x86-32 build error. v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the fio test on a different system on both bare-metal and a KVM guest. Both sockets were

v3->v4: - Fix x86-32 build error. v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the fio test on a different system on both bare-metal and a KVM guest. Both sockets were

...ently 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 vcpu_is_preempted. As kernel has used this interface, So lets support it. We use one field of struct kvm_steal_time to indicate that if one vcpu is running or not. unix benchmark result: host: kernel 4.8.1, i5-4570, 4 cpus guest: kernel 4.8.1, 8 vcpus test-case after-patch before-patch Execl Throughput | 18307.9 lps | 11701.6 lps File Copy 1024 bufsize 2000 maxblocks | 135...