All of lore.kernel.org
 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, fernando@oss.ntt.co.jp,
	takuya.yoshikawa@gmail.com
Subject: Re: [PATCH 2/2] KVM: x86: pre-allocate one more dirty bitmap to avoid vmalloc() in kvm_vm_ioctl_get_dirty_log()
Date: Wed, 09 Jun 2010 16:11:34 +0300	[thread overview]
Message-ID: <4C0F9306.3060709@redhat.com> (raw)
In-Reply-To: <20100603220618.3f77e78b.yoshikawa.takuya@oss.ntt.co.jp>

On 06/03/2010 04:06 PM, Takuya Yoshikawa wrote:
> Currently x86's kvm_vm_ioctl_get_dirty_log() needs to allocate a bitmap by
> vmalloc() which will be used in the next logging and this has been causing
> bad effects to VGA and live-migration: vmalloc() consumes extra systime,
> triggers tlb flush, etc.
>
> This patch resolves this issue by pre-allocating one more bitmap and switching
> between the two bitmaps during dirty logging.
>
> Performance improvement:
>    In the usual Desktop environment, kvm_vm_ioctl_get_dirty_log() get about
>    twice faster than the original one for graphical updates.
>
>    During live-migration with low work load, the improvement ratio was
>    about three when guest memory was 4GB.
>
>    

Looks good in general.

> Note:
>    Though this patch introduces some ifdefs, we tried not to mixing these
>    with other parts to keep the code as clean as possible.
>
>    

What's the reason for that?  Can't you update the other archs to use 
this as well?


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


  reply	other threads:[~2010-06-09 13:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03 13:01 [PATCH 1/2] KVM: introducing wrapper function for creating/destroying dirty bitmaps Takuya Yoshikawa
2010-06-03 13:06 ` [PATCH 2/2] KVM: x86: pre-allocate one more dirty bitmap to avoid vmalloc() in kvm_vm_ioctl_get_dirty_log() Takuya Yoshikawa
2010-06-09 13:11   ` Avi Kivity [this message]
2010-06-10  4:32     ` Takuya Yoshikawa

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=4C0F9306.3060709@redhat.com \
    --to=avi@redhat.com \
    --cc=fernando@oss.ntt.co.jp \
    --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 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.