kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: mtosatti@redhat.com, kvm@vger.kernel.org, takuya.yoshikawa@gmail.com
Subject: Re: [PATCH 0/4] KVM: Dirty logging optimization using rmap
Date: Mon, 14 Nov 2011 14:39:26 +0200	[thread overview]
Message-ID: <4EC10BFE.7050704@redhat.com> (raw)
In-Reply-To: <4EC0F3D3.9090907@oss.ntt.co.jp>

On 11/14/2011 12:56 PM, Takuya Yoshikawa wrote:
> (2011/11/14 19:25), Avi Kivity wrote:
>> On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
>>> This is a revised version of my previous work.  I hope that
>>> the patches are more self explanatory than before.
>>>
>>
>> It looks good.  I'll let Marcelo (or anyone else?) review it as well
>> before applying.
>>
>> Do you have performance measurements?
>>
>
> For VGA, 30-40us became 3-5us when the display was quiet, with a
> enough warmed up guest.
>

That's a nice improvement.

> Near the criterion, the number was not different much from the
> original version.
>
> For live migration, I forgot the number but the result was good.
> But my test case was not enough to cover every pattern, so I changed
> the criterion to be a bit conservative.
>
>     More tests may be able to find a better criterion.
>     I am not in a hurry about this, so it is OK to add some tests
>     before merging this.

I think we can merge is as is, it's clear we get an improvement.

>
> But what I did not like was holding spin lock more than 100us or so
> with the original version.  With this version, at least, the problem
> should be cured some.

There was a patchset from Peter Zijlstra that converted mmu notifiers to
be preemptible, with that, we can convert the mmu spinlock to a mutex,
I'll see what happened to it.

There is a third method of doing write protection, and that is by
write-protecting at the higher levels of the paging hierarchy.  The
advantage there is that write protection is O(1) no matter how large the
guest is, or the number of dirty pages.

To write protect all guest memory, we just write protect the 512 PTEs at
the very top, and leave the rest alone.  When the guest writes to a
page, we allow writes for the top-level PTE that faulted, and
write-protect all the PTEs that it points to.

We can combine it with your method by having a small bitmap (say, just
64 bits) per shadow page.  Each bit represents 8 PTEs (total 512 PTEs)
and is set if any of those PTEs are writeable.

>
>     Takuya
>
>
> One note:
>
> kvm-unit-tests' dirty logging test was broken for 32-bit box: compile
> error.
> I changed an "idt" to "boot_idt" and used it.
>
> I do not know kvm-unit-tests well, so I want somebody to fix that
> officially.

I'll look into it.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-11-14 12:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14  9:20 [PATCH 0/4] KVM: Dirty logging optimization using rmap Takuya Yoshikawa
2011-11-14  9:21 ` [PATCH 1/4] KVM: MMU: Clean up BUG_ON() conditions in rmap_write_protect() Takuya Yoshikawa
2011-11-14  9:22 ` [PATCH 2/4] KVM: MMU: Split gfn_to_rmap() into two functions Takuya Yoshikawa
2011-11-14  9:23 ` [PATCH 3/4] KVM: Count the number of dirty pages for dirty logging Takuya Yoshikawa
2011-11-14 10:07   ` Avi Kivity
2011-11-14 10:24     ` Avi Kivity
2011-12-20  4:29     ` Takuya Yoshikawa
2011-12-23 11:14       ` Marcelo Tosatti
2011-12-24  2:52         ` Takuya Yoshikawa
2011-12-27 13:50           ` Marcelo Tosatti
2011-12-27 14:03             ` Avi Kivity
2011-12-27 15:03               ` Takuya Yoshikawa
2011-12-27 15:06                 ` Avi Kivity
2011-12-27 15:15                   ` Takuya Yoshikawa
2011-12-27 15:18                     ` Avi Kivity
2011-11-14  9:24 ` [PATCH 4/4] KVM: Optimize dirty logging by rmap_write_protect() Takuya Yoshikawa
2011-11-14 10:22   ` Avi Kivity
2011-11-14 10:29     ` Takuya Yoshikawa
2011-11-14 10:25 ` [PATCH 0/4] KVM: Dirty logging optimization using rmap Avi Kivity
2011-11-14 10:56   ` Takuya Yoshikawa
2011-11-14 12:39     ` Avi Kivity [this message]
2011-11-16  4:28       ` Takuya Yoshikawa
2011-11-16  9:06         ` Avi Kivity
2011-11-29 10:01           ` Xiao Guangrong
2011-11-29 10:09             ` Xiao Guangrong
2011-11-29 10:35               ` Takuya Yoshikawa
2011-11-29 11:20                 ` Avi Kivity
2011-11-29 11:56                   ` Xiao Guangrong
2011-11-29 12:01                     ` Avi Kivity
2011-11-29 14:03                       ` Avi Kivity
2011-11-30  5:02                         ` Takuya Yoshikawa
2011-11-30  5:15                           ` Takuya Yoshikawa
2011-12-01 15:18                             ` Avi Kivity
2011-12-03  4:37                               ` Takuya Yoshikawa
2011-12-04 10:20                                 ` Avi Kivity
2011-11-30  7:10                         ` Xiao Guangrong
2011-11-30  7:03                       ` Xiao Guangrong
2011-12-01 15:11                         ` Avi Kivity
2011-11-16  8:17       ` Takuya Yoshikawa
2011-11-17  9:28 ` Avi Kivity

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=4EC10BFE.7050704@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=takuya.yoshikawa@gmail.com \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).