On 28/11/2014 12:40, Raghavendra K T wrote:
I am seeing very small improvement in = 1x commit cases
and for 1x overcommit, a very slight regression. But considering the
test environment noises, I do not see much effect from the
patch.
I think these results are the only one that could be
On 25/11/2014 17:04, David Hildenbrand wrote:
As some architectures (e.g. s390) can't disable preemption while
entering/leaving the guest, they won't receive the yield in all situations.
kvm_enter_guest() has to be called with preemption_disabled and will set
PF_VCPU. After that point e.g.
Applied with a rewritten commit message:
KVM: don't check for PF_VCPU when yielding
kvm_enter_guest() has to be called with preemption disabled and will
set PF_VCPU. Current code takes PF_VCPU as a hint that the VCPU thread
is running and therefore needs no yield.
However, the check
On 11/28/2014 04:28 PM, Christian Borntraeger wrote:
Am 28.11.2014 um 11:08 schrieb Raghavendra KT:
Was able to test the patch, here is the result: I have not tested with
bigger VMs though. Results make it difficult to talk about any side
effect of
patch if any.
Thanks a log.
If
Was able to test the patch, here is the result: I have not tested with
bigger VMs though. Results make it difficult to talk about any side
effect of
patch if any.
System 16 core 32cpu (+ht) sandybridge
with 4 guests of 16vcpu each
+---+---+---++---+
Am 28.11.2014 um 11:08 schrieb Raghavendra KT:
Was able to test the patch, here is the result: I have not tested with
bigger VMs though. Results make it difficult to talk about any side
effect of
patch if any.
Thanks a log.
If our assumption is correct, then this patch should have no side
On 11/28/2014 04:28 PM, Christian Borntraeger wrote:
Am 28.11.2014 um 11:08 schrieb Raghavendra KT:
Was able to test the patch, here is the result: I have not tested with
bigger VMs though. Results make it difficult to talk about any side
effect of
patch if any.
Thanks a log.
If our
This change is a trade-off.
PRO: This patch would improve the case of preemption on s390. This is
probably a corner case as most distros have preemption off anyway.
CON: The downside is that kvm_vcpu_yield_to is called also from
kvm_vcpu_on_spin. Here we want to avoid the scheduler overhead
Am 26.11.2014 um 10:23 schrieb David Hildenbrand:
This change is a trade-off.
PRO: This patch would improve the case of preemption on s390. This is
probably a corner case as most distros have preemption off anyway.
CON: The downside is that kvm_vcpu_yield_to is called also from
As some architectures (e.g. s390) can't disable preemption while
entering/leaving the guest, they won't receive the yield in all situations.
kvm_enter_guest() has to be called with preemption_disabled and will set
PF_VCPU. After that point e.g. s390 reenables preemption and starts to execute
the
Am 25.11.2014 um 17:04 schrieb David Hildenbrand:
As some architectures (e.g. s390) can't disable preemption while
entering/leaving the guest, they won't receive the yield in all situations.
kvm_enter_guest() has to be called with preemption_disabled and will set
PF_VCPU. After that point
11 matches
Mail list logo
