On Mon, 1 Nov 2010, Takuya Yoshikawa wrote:
> (2010/10/31 3:28), Jesper Juhl wrote:
> > Hi,
> >
> > We can improve kvm_vm_ioctl_get_dirty_log() slightly by using vzalloc()
> > rather than first allocating and then manually zero the memory with
> > memset(). Also, while I was looking at this I noticed that we assign
>
> I personally prefer this new vzalloc() to vmalloc() + memset().
>
> Just from my interest, is there real performance difference not just
> the cleanup effect? If so, we'd better do this for other places too.
>
There's definately a positive size impact for the generated object code
and we save having to do the call to memset() and the cost of a vzalloc()
call looks more or less the same as a call to vmalloc() to me.
<snip>
>
> This patch is not based on kvm.git, I guess.
>
Nope. It was generated against mainline git as of a couple of days ago. I
can generate a version against kvm.git if you prefer.
> > r = -ENOMEM;
> > - dirty_bitmap = vmalloc(n);
> > + dirty_bitmap = vzalloc(n);
> > if (!dirty_bitmap)
> > goto out;
> > - memset(dirty_bitmap, 0, n);
> >
> > - r = -ENOMEM;
>
> This one is here because this belongs to a different code block from the
> previous one. This keeps it easy to insert another codes in between these
> two blocks. The optimization will be done at compile time.
> IIRC, I did like this based on Avi's advise.
>
Fair enough, I've dropped that bit from the patch. Updated version below
(against current mainline git).
Signed-off-by: Jesper Juhl <[email protected]>
---
x86.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2288ad8..624d4da 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3174,10 +3174,9 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
spin_unlock(&kvm->mmu_lock);
r = -ENOMEM;
- dirty_bitmap = vmalloc(n);
+ dirty_bitmap = vzalloc(n);
if (!dirty_bitmap)
goto out;
- memset(dirty_bitmap, 0, n);
r = -ENOMEM;
slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Hi Jesper, (dropped some addresses from Cc)
> > Jesper Juhl wrote:
> There's definately a positive size impact for the generated object code
> and we save having to do the call to memset() and the cost of a vzalloc()
> call looks more or less the same as a call to vmalloc() to me.
> > This patch is not based on kvm.git, I guess.
> >
> Nope. It was generated against mainline git as of a couple of days ago. I
> can generate a version against kvm.git if you prefer.
Sorry, I should have said more clearly.
kvm_vm_ioctl_get_dirty_log() has been changed since latest mainline kernel was released.
Furthermore, vmalloc() in it is to be removed soon, currently in kvm's next.
I have checked all vmalloc() + memset() in kvm, and there are three remaining.
See the patch below.
- I have tested on x86.
- I can test ppc later if needed, but this is so trivial that Alex will see
no problem about this, probably.
So please write your Signed-off-by and ask Avi and Marcelo to apply.
Thanks,
Takuya
===
Subject: [PATCH] KVM: replace vmalloc and memset with vzalloc
Let's use newly introduced vzalloc().
Signed-off-by: Takuya Yoshikawa <[email protected]>
Cc: Jesper Juhl <[email protected]>
---
arch/powerpc/kvm/book3s.c | 4 +---
virt/kvm/kvm_main.c | 9 ++-------
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index e316847..badc983 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -1307,12 +1307,10 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
int err = -ENOMEM;
unsigned long p;
- vcpu_book3s = vmalloc(sizeof(struct kvmppc_vcpu_book3s));
+ vcpu_book3s = vzalloc(sizeof(struct kvmppc_vcpu_book3s));
if (!vcpu_book3s)
goto out;
- memset(vcpu_book3s, 0, sizeof(struct kvmppc_vcpu_book3s));
-
vcpu_book3s->shadow_vcpu = (struct kvmppc_book3s_shadow_vcpu *)
kzalloc(sizeof(*vcpu_book3s->shadow_vcpu), GFP_KERNEL);
if (!vcpu_book3s->shadow_vcpu)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index dbe1d6a..bd44a81 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -606,13 +606,11 @@ int __kvm_set_memory_region(struct kvm *kvm,
/* Allocate if a slot is being created */
#ifndef CONFIG_S390
if (npages && !new.rmap) {
- new.rmap = vmalloc(npages * sizeof(*new.rmap));
+ new.rmap = vzalloc(npages * sizeof(*new.rmap));
if (!new.rmap)
goto out_free;
- memset(new.rmap, 0, npages * sizeof(*new.rmap));
-
new.user_alloc = user_alloc;
new.userspace_addr = mem->userspace_addr;
}
@@ -635,14 +633,11 @@ int __kvm_set_memory_region(struct kvm *kvm,
>> KVM_HPAGE_GFN_SHIFT(level));
lpages -= base_gfn >> KVM_HPAGE_GFN_SHIFT(level);
- new.lpage_info[i] = vmalloc(lpages * sizeof(*new.lpage_info[i]));
+ new.lpage_info[i] = vzalloc(lpages * sizeof(*new.lpage_info[i]));
if (!new.lpage_info[i])
goto out_free;
- memset(new.lpage_info[i], 0,
- lpages * sizeof(*new.lpage_info[i]));
-
if (base_gfn & (KVM_PAGES_PER_HPAGE(level) - 1))
new.lpage_info[i][0].write_count = 1;
if ((base_gfn+npages) & (KVM_PAGES_PER_HPAGE(level) - 1))
--
1.7.0.4
On Tue, 2 Nov 2010, Takuya Yoshikawa wrote:
> Hi Jesper, (dropped some addresses from Cc)
>
> > > Jesper Juhl wrote:
> > There's definately a positive size impact for the generated object code
> > and we save having to do the call to memset() and the cost of a vzalloc()
> > call looks more or less the same as a call to vmalloc() to me.
>
> > > This patch is not based on kvm.git, I guess.
> > >
> > Nope. It was generated against mainline git as of a couple of days ago. I
> > can generate a version against kvm.git if you prefer.
>
> Sorry, I should have said more clearly.
>
> kvm_vm_ioctl_get_dirty_log() has been changed since latest mainline kernel was released.
> Furthermore, vmalloc() in it is to be removed soon, currently in kvm's next.
>
> I have checked all vmalloc() + memset() in kvm, and there are three remaining.
> See the patch below.
> - I have tested on x86.
> - I can test ppc later if needed, but this is so trivial that Alex will see
> no problem about this, probably.
>
> So please write your Signed-off-by and ask Avi and Marcelo to apply.
>
> Thanks,
> Takuya
>
> ===
> Subject: [PATCH] KVM: replace vmalloc and memset with vzalloc
>
> Let's use newly introduced vzalloc().
>
> Signed-off-by: Takuya Yoshikawa <[email protected]>
Signed-off-by: Jesper-juhl <[email protected]>
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
On Tue, Nov 02, 2010 at 05:11:19AM +0100, Jesper Juhl wrote:
> On Tue, 2 Nov 2010, Takuya Yoshikawa wrote:
>
> > Hi Jesper, (dropped some addresses from Cc)
> >
> > > > Jesper Juhl wrote:
> > > There's definately a positive size impact for the generated object code
> > > and we save having to do the call to memset() and the cost of a vzalloc()
> > > call looks more or less the same as a call to vmalloc() to me.
> >
> > > > This patch is not based on kvm.git, I guess.
> > > >
> > > Nope. It was generated against mainline git as of a couple of days ago. I
> > > can generate a version against kvm.git if you prefer.
> >
> > Sorry, I should have said more clearly.
> >
> > kvm_vm_ioctl_get_dirty_log() has been changed since latest mainline kernel was released.
> > Furthermore, vmalloc() in it is to be removed soon, currently in kvm's next.
> >
> > I have checked all vmalloc() + memset() in kvm, and there are three remaining.
> > See the patch below.
> > - I have tested on x86.
> > - I can test ppc later if needed, but this is so trivial that Alex will see
> > no problem about this, probably.
> >
> > So please write your Signed-off-by and ask Avi and Marcelo to apply.
> >
> > Thanks,
> > Takuya
> >
> > ===
> > Subject: [PATCH] KVM: replace vmalloc and memset with vzalloc
> >
> > Let's use newly introduced vzalloc().
> >
> > Signed-off-by: Takuya Yoshikawa <[email protected]>
>
> Signed-off-by: Jesper-juhl <[email protected]>
Applied, thanks.