[Qemu-devel] Re: [RFC] KVM Fault Tolerance: Kemari for KVM

[Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>]

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

2009/11/18 Avi Kivity <avi@redhat.com>:
> On 11/18/2009 03:28 PM, Yoshiaki Tamura wrote:
>>
>>> I don't think lmbench is intensive but it's sensitive to memory latency.
>>> We'll measure kernel build time with minimum config, and post it later.
>>>
>>
>> Here are some quick numbers of parallel kernel compile time.
>> The number of vcpu is 1, just for convenience.
>>
>> time make -j 2 all
>>
>> -----------------------------------------------------------------------------
>> Base:    real 1m13.950s (user 1m2.742s, sys 0m10.446s)
>> Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s)
>>
>> time make -j 4 all
>>
>> -----------------------------------------------------------------------------
>> Base:    real 1m11.234s (user 1m2.582s, sys 0m8.643s)
>> Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s)
>>
>> The result of Kemari includes everything, meaning dirty pages tracking and
>> synchronization upon I/O operations to the disk.
>> The compile time using j=4 under Kemari was worse than that of j=2,
>> but I'm not sure this is due to dirty pages tracking or sync interval.
>>
>
> Do disk writes trigger synchronization?  Otherwise this is a very relaxed
> test.  I'm surprised the degradation is so low running continuously in
> log-dirty.

They do.  I double checked the traffic on the synchronization network.
Attached file is a graph that shows the traffic during kernel compiling under
Kemari.  It seems j=4 produces more traffic than j=2, and after finishing
compilation, both of the traffic drop to the normal rate.

> Is this an npt or ept system?  Without npt or ept I'd expect less
> degradation since the page tables are heavily manipulated anyway.

This is an ept system indeed.  If properly implemented, Kemari should
work not only on x86 but also on other archs, and I'm interested in how
the numbers would differ.

Thanks,

Yoshi

> --
> Do not meddle in the internals of kernels, for they are subtle and quick to
> panic.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[-- Attachment #2: kernel-compile-traffic.pdf --]
[-- Type: application/pdf, Size: 23813 bytes --]