Re: QEMU PIC indirection patch for in-kernel APIC work

Dong, Eddie
2007-04-05T15:16:32Z

Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>>
>>>> With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ
>>>> linux kernel, KB gets 14% gain. We also did a shared PIC model
>>>> which share PIC state among Qemu & VMM with less LOC in VMM, it
>>>> can get
>>>> similar performance gain (5.8% in my test).
>>>> BTW, at that time, PIT is in VMM already.
>>>>
>>>>
>>> I expect that the gain in kvm will be smaller. Xen has to schedule
>>> dom0 to process the event channel (possibly on another cpu), dom0
>>> has to schedule qemu-dm (again, possibly on another cpu), qemu does
>>> its thing, and then Xen has to schedule domU again. With kvm, we
>>> are always on the same cpu, and the only overhead is the system
>>> call, which is a few hundred nanoseconds. I expect with current
>>> hardware that it will be negligible (as a vmexit is measured in
>>> microseconds), but to become measurable as hardware improves.
>>>
>> Yes very possible.
>> We can take a quick mesurement to see how many cycles are spent in a
>> dummy I/O emulation in KVM/Qemu. In Xen, one of my old P4 3.8GHZ
>> platform takes about 50-60K cycles. We can see how many is it in KVM.
>> BTW, today Linux kernel is no longer 1000HZ :-)
>> thx,eddie
>>
>
> There's some (old) data here:
>
> http://virt.kernelnewbies.org/KVM/Performance
>
> showing pio latency of ~5600 cycles. Note that this is on AMD, which
> takes less cycles to switch than the P4, but on the other hand, we
> still do a save/restore of the fpu state on every exit, so we can
> speed it up even more.

That is great I/O performance difference between Xen & KVM though the
sample data
is too small (100 delta's were used). We can try with more samples to
let it last for several
minutes to include many scheduler events that we used before.
On the otherhand, it proves that context switch between KVM and Qemu is
quit lightweight
given that there is no domain switch and even no guest task switch in
most case.
Thanks, eddie