search for: kvm_sched_out

...times before this > vCPU is scheded in, then the first time we can get "vCPU is > preempted", however, since the field is cleared, the second time we > will get "vCPU is running". > > Do you mean we should call record_steal_time() in both kvm_sched_in() > and kvm_sched_out() to record this field? Btw, if we should keep both > vcpu->preempted and kvm_steal_time's "vCPU preempted" field present > simultaneous? I suspect you want something like so; except this has holes in. We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it af...

...times before this > vCPU is scheded in, then the first time we can get "vCPU is > preempted", however, since the field is cleared, the second time we > will get "vCPU is running". > > Do you mean we should call record_steal_time() in both kvm_sched_in() > and kvm_sched_out() to record this field? Btw, if we should keep both > vcpu->preempted and kvm_steal_time's "vCPU preempted" field present > simultaneous? I suspect you want something like so; except this has holes in. We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it af...

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

...> vCPU is scheded in, then the first time we can get "vCPU is >> preempted", however, since the field is cleared, the second time we >> will get "vCPU is running". >> >> Do you mean we should call record_steal_time() in both kvm_sched_in() >> and kvm_sched_out() to record this field? Btw, if we should keep both >> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present >> simultaneous? > > I suspect you want something like so; except this has holes in. > > We clear KVM_ST_PAD_PREEMPT before disabling p...

...ed, and guest check it several times before this vCPU is scheded in, then the first time we can get "vCPU is preempted", however, since the field is cleared, the second time we will get "vCPU is running". Do you mean we should call record_steal_time() in both kvm_sched_in() and kvm_sched_out() to record this field? Btw, if we should keep both vcpu->preempted and kvm_steal_time's "vCPU preempted" field present simultaneous? Regards, Wanpeng Li

...in, then the first time we can get "vCPU is >>> preempted", however, since the field is cleared, the second time we >>> will get "vCPU is running". >>> >>> Do you mean we should call record_steal_time() in both kvm_sched_in() >>> and kvm_sched_out() to record this field? Btw, if we should keep both >>> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present >>> simultaneous? >> >> I suspect you want something like so; except this has holes in. >> >> We clear KVM_ST_PAD_PR...

...in, then the first time we can get "vCPU is >>> preempted", however, since the field is cleared, the second time we >>> will get "vCPU is running". >>> >>> Do you mean we should call record_steal_time() in both kvm_sched_in() >>> and kvm_sched_out() to record this field? Btw, if we should keep both >>> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present >>> simultaneous? >> >> I suspect you want something like so; except this has holes in. >> >> We clear KVM_ST_PAD_PR...