Re: [PATCH RFC v2 5/6] KVM: moving dirty bitmaps to user space

Yoshiaki Tamura
2010-04-23T11:29:40Z

2010/4/23 Takuya Yoshikawa <yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>:
> (2010/04/23 19:28), Avi Kivity wrote:
>
>>>
>>> OK, I will do in the next version. In this RFC, I would be happy if I can
>>> know the overall design is right or not.
>>>
>>
>> Everything looks reasonable to me.
>>
>
> Thank you!
>
>> Do you have performance numbers? I'm interested in both measurements of
>> KVM_SWITCH_DIRTY_LOG under various conditions and macro benchmarks (for
>> example, total guest throughput improvement under Kemari).
>>
>
> Currently, I'm just checking the performance visually.
>  - on laptops, we can feel the speed directly: my favorite is installing
>    ubuntu or debian by alternate installers
>
>  - live migration with heavy work load
>
> Now that I've got the overall design, I want to measure the performance by
> numbers.
>
>
> About performance under Kemari: we(oss.ntt.co.jp staffs: me and Fernando)
> are
> now concentrating on improving the basic live-migration infrastructures and
> they(lab.ntt.co.jp staffs) are working hard for building Kemari itself.
>
>  - We are also interested in using live-migration with HA software and this
> needs
>    light, stable live-migration: same as Kemari!
>
>
> So measuring Kemari's performance with our patch-set will need some more
> time,
> ** How about Tamura-san? **

You can measure your patch quite easy.

1. Run a simple program that malloc huge size (2GB for example), then
go into infinite loop that touches each in a really bad manner, like
only touch odd page numbers.
2. Start live migration which usually won't finish. Similar with Kemari.
3. Measure the response time of your ioctl().

I used 1 and 2 to measure dirty physmap speed up in QEMU.

Thanks,

Yoshi

> So at this stage, I'll show you performance improvement(I hope to improve)
> by
> another test cases.
>
> If possible next week!
>
> Thanks,
>  Takuya
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>