From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v4 06/10] KVM: MMU: fast path of handling guest page fault Date: Thu, 03 May 2012 20:23:18 +0800 Message-ID: <4FA278B6.5090208@linux.vnet.ibm.com> References: <4F9776D2.7020506@linux.vnet.ibm.com> <4F9777A4.208@linux.vnet.ibm.com> <20120426234535.GA5057@amt.cnet> <4F9A3445.2060305@linux.vnet.ibm.com> <20120427145213.GB28796@amt.cnet> <20120429175004.b54d8c095a60d98c8cdbc942@gmail.com> <4FA0C8A7.9000001@linux.vnet.ibm.com> <20120503091558.866e158916f0dd67daf5a9a2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , Avi Kivity , LKML , KVM To: Takuya Yoshikawa Return-path: In-Reply-To: <20120503091558.866e158916f0dd67daf5a9a2@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/03/2012 08:15 AM, Takuya Yoshikawa wrote: > On Wed, 02 May 2012 13:39:51 +0800 > Xiao Guangrong wrote: >=20 >>> Was the problem really mmu_lock contention? >=20 >> Takuya, i am so tired to argue the advantage of lockless write-prote= ct >> and lockless O(1) dirty-log again and again. >=20 > You are missing my point. Please do not take my comments as an objec= tion > to your whole work: whey do you feel so? >=20 Takuya, i am sorry, please forgive my rudeness! Since my English is so poor that it is easy for me to misunderstand the mail.=E3=80=80:( > I thought that your new fast-page-fault path was fast and optimized > the guest during dirty logging. >=20 > So in this v4, you might get a similar result even before dropping > mmu_lock, without 07/10?, if the problem Marcelo explained was not th= ere. >=20 Actually, the improvement is larger than v2/v3 if ept is enabled, but it is lower for ept disabled. This is because the fask-fask (rmap.WRITA= BLE bit) is dropped for better review. >=20 > Of course there is a problem of mmu_lock contention. What I am sugge= sting > is to split that problem and do measurement separately so that part o= f > your work can be merged soon. >=20 > Your guest size and workload was small to make get_dirty hold mmu_loc= k > long time. If you want to appeal the real value of lock-less, you ne= ed to > do another measurment. >=20 >=20 > But this is your work and it's up to you. Although I was thinking to= help > your measurement, I cannot do that knowing the fact that you would no= t > welcome my help. >=20 Of course, any measurement is appreciative! >=20 >>> Although I am not certain about what will be really needed in the >>> final form, if this kind of maybe-needed-overhead is going to be >>> added little by little, I worry about possible regression. >=20 >> Well, will you suggest Linus to reject all patches and stop >> all discussion for the "possible regression" reason? >=20 > My concern was for Marcelo's examples, not your current implementatio= n. > If you can show explicitely what will be needed in the final form, > I do not have any concern. >=20 >=20 > Sorry for disturbing. Sorry again.