Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> Dong, Eddie wrote:
>>
>>> In this case, IOCTL return to Qemu will trigger scheduling at least.
>>>
>>>
>> I think a scheduling change won't happen until the next timer tick.
>> AFAICT, there's nothing explicit in the ioctl return pa
Anthony Liguori wrote:
> Dong, Eddie wrote:
>> In this case, IOCTL return to Qemu will trigger scheduling at least.
>>
>
> I think a scheduling change won't happen until the next timer tick.
> AFAICT, there's nothing explicit in the ioctl return path that will
> result in rescheduling.
>
> I'm
Dong, Eddie wrote:
> Actually I am thinking to totally give up kvm_resched and just let
> control return to Qemu which is much clean and provide Qemu
> more chance to handle some kind of hardware event such as network
> packet arrive etc. Today Qemu is totally depending on heavyweight VM
> Exit
Dong, Eddie wrote:
> Anthony Liguori wrote:
>
>> Dong, Eddie wrote:
>>
>>> In this case, IOCTL return to Qemu will trigger scheduling at least.
>>>
>>>
>> I think a scheduling change won't happen until the next timer tick.
>> AFAICT, there's nothing explicit in the ioctl return path
Anthony Liguori wrote:
> Dong, Eddie wrote:
>> In this case, IOCTL return to Qemu will trigger scheduling at least.
>>
>
> I think a scheduling change won't happen until the next timer tick.
> AFAICT, there's nothing explicit in the ioctl return path that will
> result in rescheduling.
Do u mean
Dong, Eddie wrote:
> In this case, IOCTL return to Qemu will trigger scheduling at least.
>
I think a scheduling change won't happen until the next timer tick.
AFAICT, there's nothing explicit in the ioctl return path that will
result in rescheduling.
I'm not entirely confident in how the t
Anthony Liguori wrote:
> Dong, Eddie wrote:
>> Anthony Liguori wrote:
>>
>>> This should get moved to kvm_resched() since both VT/SVM would
>>> benefit from this.
>>>
>>>
>> I would suggest we just add similar code in SVM side. After we
>> optimize the MSR/VMCS register save/restore to skip for
Dong, Eddie wrote:
> Anthony Liguori wrote:
>
>> This should get moved to kvm_resched() since both VT/SVM would benefit
>> from this.
>>
>>
> I would suggest we just add similar code in SVM side. After we
> optimize the MSR/VMCS register save/restore to skip for
> those lightweight VM EXI
Anthony Liguori wrote:
>
> This should get moved to kvm_resched() since both VT/SVM would benefit
> from this.
>
I would suggest we just add similar code in SVM side. After we
optimize the MSR/VMCS register save/restore to skip for
those lightweight VM EXIT (handled by KVM). Giving up preemptio
Anthony Liguori wrote:
> Dong, Eddie wrote:
>> A minor change to reduce vcpu_put/vcpu_load frequency (still base on
>> KVM-18). Not sure if you would like to see this?
>>
>> Signed-off-by: Yaozu Dong <[EMAIL PROTECTED]>
>>
>> --- vmx.old2007-04-25 20:28:19.0 +0800
>> +++ vmx.new2007
Dong, Eddie wrote:
> A minor change to reduce vcpu_put/vcpu_load frequency (still base on
> KVM-18). Not sure if you would like to see this?
>
> Signed-off-by: Yaozu Dong <[EMAIL PROTECTED]>
>
> --- vmx.old 2007-04-25 20:28:19.0 +0800
> +++ vmx.new 2007-04-25 20:28:10.0 +0800
>
Dong, Eddie wrote:
> Here it is.
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express
Avi Kivity wrote:
> Dong, Eddie wrote:
>> A minor change to reduce vcpu_put/vcpu_load frequency (still base on
>> KVM-18). Not sure if you would like to see this?
>>
>> Signed-off-by: Yaozu Dong <[EMAIL PROTECTED]>
>>
>> --- vmx.old 2007-04-25 20:28:19.0 +0800
>> +++ vmx.new 2007-04-25
Dong, Eddie wrote:
> A minor change to reduce vcpu_put/vcpu_load frequency (still base on
> KVM-18). Not sure if you would like to see this?
>
> Signed-off-by: Yaozu Dong <[EMAIL PROTECTED]>
>
> --- vmx.old 2007-04-25 20:28:19.0 +0800
> +++ vmx.new 2007-04-25 20:28:10.0 +0800
>
14 matches
Mail list logo
