diff options
author | Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> | 2013-01-22 13:09:24 +0530 |
---|---|---|
committer | Gleb Natapov <gleb@redhat.com> | 2013-01-29 15:38:45 +0200 |
commit | c45c528e899094b9049b3c900e2cf1f00aa0490c (patch) | |
tree | ee8562c37a74f74f9fbc30772a3bc4e7c69db8d6 /kernel/Kconfig.hz | |
parent | 7b270f609982f68f2433442bf167f735e7364b06 (diff) |
kvm: Handle yield_to failure return code for potential undercommit case
yield_to returns -ESRCH, When source and target of yield_to
run queue length is one. When we see three successive failures of
yield_to we assume we are in potential undercommit case and abort
from PLE handler.
The assumption is backed by low probability of wrong decision
for even worst case scenarios such as average runqueue length
between 1 and 2.
More detail on rationale behind using three tries:
if p is the probability of finding rq length one on a particular cpu,
and if we do n tries, then probability of exiting ple handler is:
p^(n+1) [ because we would have come across one source with rq length
1 and n target cpu rqs with length 1 ]
so
num tries: probability of aborting ple handler (1.5x overcommit)
1 1/4
2 1/8
3 1/16
We can increase this probability with more tries, but the problem is
the overhead.
Also, If we have tried three times that means we would have iterated
over 3 good eligible vcpus along with many non-eligible candidates. In
worst case if we iterate all the vcpus, we reduce 1x performance and
overcommit performance get hit.
note that we do not update last boosted vcpu in failure cases.
Thank Avi for raising question on aborting after first fail from yield_to.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Diffstat (limited to 'kernel/Kconfig.hz')
0 files changed, 0 insertions, 0 deletions