From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>, Avi Kivity <avi@redhat.com>,
Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Rik van Riel <riel@redhat.com>,
Srikar <srikar@linux.vnet.ibm.com>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
KVM <kvm@vger.kernel.org>, Jiannan Ouyang <ouyang@cs.pitt.edu>,
Chegu Vinod <chegu_vinod@hp.com>,
"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>,
Andrew Jones <drjones@redhat.com>
Subject: Re: [PATCH V3 RFC 2/2] kvm: Handle yield_to failure return code for potential undercommit case
Date: Mon, 3 Dec 2012 17:56:20 -0200 [thread overview]
Message-ID: <20121203195620.GB590@amt.cnet> (raw)
In-Reply-To: <50B59CE0.70305@linux.vnet.ibm.com>
On Wed, Nov 28, 2012 at 10:40:56AM +0530, Raghavendra K T wrote:
> On 11/28/2012 06:42 AM, Marcelo Tosatti wrote:
> >
> >Don't understand the reasoning behind why 3 is a good choice.
>
> Here is where I came from. (explaining from scratch for
> completeness, forgive me :))
> In moderate overcommits, we can falsely exit from ple handler even when
> we have preempted task of same VM waiting on other cpus. To reduce this
> problem, we try few times before exiting.
> The problem boils down to:
> what is the probability that we exit ple handler even when we have more
> than 1 task in other cpus. Theoretical worst case should be around 1.5x
> overcommit (As also pointed by Andrew Theurer). [But practical
> worstcase may be around 2x,3x overcommits as indicated by the results
> for the patch series]
>
> So 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. [ as in results ].
>
> I have tried num_tries = 1,2,3 and n already ( not 4 yet). So I
> concluded 3 is enough.
>
> Infact I have also run kernbench and hackbench which are giving 5-20%
> improvement.
>
> [ As a side note , I also thought how about having num_tries = f(n) =
> ceil ( log(num_online_cpus)/2 ) But I thought calculation is too much
> overhead and also there is no point in probably making it dependent on
> online cpus ]
>
> Please let me know if you are happy with this rationale/ or correct me
> if you foresee some problem. (Infact Avi, Rik's concern about false
> exiting made me arrive at 'try' logic which I did not have earlier).
>
> I am currently trying out the result for 1.5x overcommit will post the
> result.
Raghavendra
Makes sense to me. Thanks.
next prev parent reply other threads:[~2012-12-03 19:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-26 12:07 [PATCH V3 RFC 0/2] kvm: Improving undercommit scenarios Raghavendra K T
2012-11-26 12:07 ` [PATCH V3 RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task Raghavendra K T
2012-11-26 13:35 ` Andrew Jones
2012-11-27 10:30 ` Raghavendra K T
2012-11-27 14:04 ` Andrew Theurer
2012-11-28 7:03 ` Raghavendra K T
2012-11-27 14:23 ` Chegu Vinod
[not found] ` <50B68F94.3080907@hp.com>
2012-11-29 2:00 ` Andrew Theurer
[not found] ` <50B6B5B5.5060108@hp.com>
2012-11-29 2:20 ` Chegu Vinod
2012-12-14 0:29 ` Marcelo Tosatti
2012-12-14 15:40 ` Raghavendra K T
2012-12-19 5:35 ` Raghavendra K T
2012-11-26 12:08 ` [PATCH V3 RFC 2/2] kvm: Handle yield_to failure return code for potential undercommit case Raghavendra K T
2012-11-26 13:43 ` Andrew Jones
2012-11-26 14:06 ` Andrew Jones
2012-11-27 10:27 ` Raghavendra K T
2012-11-27 13:22 ` Andrew Jones
2012-11-28 1:12 ` Marcelo Tosatti
2012-11-28 5:10 ` Raghavendra K T
2012-11-29 12:16 ` Gleb Natapov
2012-11-30 5:04 ` Raghavendra K T
2012-12-03 19:56 ` Marcelo Tosatti [this message]
2012-12-04 17:49 ` Raghavendra K T
2012-12-06 6:59 ` Raghavendra K T
2012-12-08 0:49 ` Marcelo Tosatti
2012-11-29 2:07 ` [PATCH V3 RFC 0/2] kvm: Improving undercommit scenarios Chegu Vinod
2012-11-29 9:49 ` Raghavendra K T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121203195620.GB590@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=chegu_vinod@hp.com \
--cc=drjones@redhat.com \
--cc=gleb@redhat.com \
--cc=habanero@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=ouyang@cs.pitt.edu \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=riel@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=srivatsa.vaddagiri@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.