All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: MMU: lazily drop large spte
Date: Tue, 13 Nov 2012 16:26:16 +0800	[thread overview]
Message-ID: <50A20428.1030004@linux.vnet.ibm.com> (raw)
In-Reply-To: <20121112231032.GB5798@amt.cnet>

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

Hi Marcelo,

On 11/13/2012 07:10 AM, Marcelo Tosatti wrote:
> On Mon, Nov 05, 2012 at 05:59:26PM +0800, Xiao Guangrong wrote:
>> Do not drop large spte until it can be insteaded by small pages so that
>> the guest can happliy read memory through it
>>
>> The idea is from Avi:
>> | As I mentioned before, write-protecting a large spte is a good idea,
>> | since it moves some work from protect-time to fault-time, so it reduces
>> | jitter.  This removes the need for the return value.
>>
>> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
>> ---
>>  arch/x86/kvm/mmu.c |   34 +++++++++-------------------------
>>  1 files changed, 9 insertions(+), 25 deletions(-)
> 
> Its likely that other 4k pages are mapped read-write in the 2mb range 
> covered by a read-only 2mb map. Therefore its not entirely useful to
> map read-only. 
> 

It needs a page fault to install a pte even if it is the read access.
After the change, the page fault can be avoided.

> Can you measure an improvement with this change?

I have a test case to measure the read time which has been attached.
It maps 4k pages at first (dirt-loggged), then switch to large sptes
(stop dirt-logging), at the last, measure the read access time after write
protect sptes.

Before: 23314111 ns	After: 11404197 ns

[-- Attachment #2: testcase.tar.bz2 --]
[-- Type: application/x-bzip, Size: 8444 bytes --]

  reply	other threads:[~2012-11-13  8:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05  9:59 [PATCH] KVM: MMU: lazily drop large spte Xiao Guangrong
2012-11-12 23:10 ` Marcelo Tosatti
2012-11-13  8:26   ` Xiao Guangrong [this message]
2012-11-14 14:37     ` Marcelo Tosatti
2012-11-14 23:17       ` Xiao Guangrong
2012-11-16  3:02         ` Marcelo Tosatti
2012-11-16  3:39           ` Xiao Guangrong
2012-11-16  3:56             ` Marcelo Tosatti
2012-11-16  4:46               ` Xiao Guangrong
2012-11-16  9:57                 ` Marcelo Tosatti
2012-11-17 14:06                   ` Xiao Guangrong
2012-11-18  3:00                     ` Marcelo Tosatti
2012-11-28  5:27                       ` Xiao Guangrong
2012-11-28 11:39                         ` Marcelo Tosatti
2012-11-13 15:33   ` Takuya Yoshikawa
2012-11-14 14:44     ` Marcelo Tosatti
2012-11-14 23:33       ` Xiao Guangrong

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=50A20428.1030004@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.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.