From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junaid Shahid Subject: Re: [PATCH v3 3/8] kvm: x86: mmu: Fast Page Fault path retries Date: Fri, 16 Dec 2016 16:36:52 -0800 Message-ID: <4566496.4t04x2UviG@js-desktop.mtv.corp.google.com> References: <10369248.Ox3tqWMzUc@js-desktop.mtv.corp.google.com> <39de04e1-af5c-7c65-800c-bfb3295ba660@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: kvm@vger.kernel.org, andreslc@google.com, pfeiner@google.com, pbonzini@redhat.com To: Xiao Guangrong Return-path: Received: from mail-pg0-f52.google.com ([74.125.83.52]:36453 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755398AbcLQAgy (ORCPT ); Fri, 16 Dec 2016 19:36:54 -0500 Received: by mail-pg0-f52.google.com with SMTP id f188so37375851pgc.3 for ; Fri, 16 Dec 2016 16:36:53 -0800 (PST) In-Reply-To: <39de04e1-af5c-7c65-800c-bfb3295ba660@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Friday, December 16, 2016 09:13:13 PM Xiao Guangrong wrote: >=20 > I mean the it is unlinked from the upper level page structure. >=20 Ah, ok. But even in that case, the retries won=E2=80=99t happen unless = somebody was actively trying to write to the just unlinked page table a= t the same time, which can cause bigger problems. In any case, I can mo= ve the pgtable walk inside the loop, as there doesn=E2=80=99t seem to b= e any downside in it. > > > >> I am curious that did you see this retry is really helpful? :) > > > > No, I haven=E2=80=99t done a comparison with and without the retrie= s since it seemed to be a fairly simple optimization. And it may not be= straightforward to reliably reproduce the situation where it will help= . >=20 > So we are not sure if retry is really useful... >=20 > After this change, all !W page fault can go to this fast path, i thin= k it does not hurt the > performance, but we'd better have a performance test. Yes, more faults can go into this fast path now. However, all except th= ose where we actually need to fix the acc-tracking or write-prot will b= reak out in the first iteration, so the retries won=E2=80=99t happen fo= r those. For the cases where we actually do retry, the alternative coul= d be another VMEXIT, which would obviously be a lot more expensive. But= I=E2=80=99ll try to think of some way to test the performance. Thanks, Junaid