# Re: [PATCH V3 RFC 2/2] kvm: Handle yield_to failure return code forpotential undercommit case

From: Raghavendra K T
Date: Tue Dec 04 2012 - 12:50:50 EST

On 12/04/2012 01:26 AM, Marcelo Tosatti wrote:
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
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.

Hi Marcelo, Thanks for looking into patches.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html