| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <50C04236.4020406@linux.vnet.ibm.com> Date: Thu, 06 Dec 2012 12:29:02 +0530 From: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com> To: Marcelo Tosatti <mtosatti@...hat.com> CC: Peter Zijlstra <peterz@...radead.org>, "H. Peter Anvin" <hpa@...or.com>, Avi Kivity <avi@...hat.com>, Gleb Natapov <gleb@...hat.com>, Ingo Molnar <mingo@...hat.com>, Rik van Riel <riel@...hat.com>, Srikar <srikar@...ux.vnet.ibm.com>, "Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>, KVM <kvm@...r.kernel.org>, Jiannan Ouyang <ouyang@...pitt.edu>, Chegu Vinod <chegu_vinod@...com>, "Andrew M. Theurer" <habanero@...ux.vnet.ibm.com>, LKML <linux-kernel@...r.kernel.org>, Srivatsa Vaddagiri <srivatsa.vaddagiri@...il.com>, Andrew Jones <drjones@...hat.com> Subject: Re: [PATCH V3 RFC 2/2] kvm: Handle yield_to failure return code for potential undercommit case 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 >> 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. > Marcelo, Do you think this can be considered for next merge window? or you are expecting anything else on this patchset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists