qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucur


From: Avi Kivity
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
Date: Tue, 21 Aug 2007 15:09:43 +0300
User-agent: Thunderbird 2.0.0.0 (X11/20070419)

Luca Tettamanti wrote:
Run a 100Hz guest, measure cpu usage using something accurate like
cyclesoak, with and without dynticks, with and without kvm.

Ok, here I've measured the CPU usage on the host when running an idle
guest.

At 100Hz

QEMU
hpet            4.8%
dynticks        5.1%

Note: I've taken the mean over a period of 20 secs, but the difference
between hpet and dynticks is well inside the variability of the test.

KVM
hpet            2.2%
dynticks        1.0%

Hum... here the numbers jumps a bit, but dynticks is always below hpet.

The differences here are small, so I'll focus on the 1000Hz case.

At 1000Hz:

QEMU
hpet            5.5%
dynticks       11.7%

KVM
hpet            3.4%
dynticks        7.3%

No surprises here, you can see the additional 1k syscalls per second.

This is very surprising to me. The 6.2% difference for the qemu case translates to 62ms per second, or 62us per tick at 1000Hz. That's more than a hundred simple syscalls on modern processors. We shouldn't have to issue a hundred syscalls per guest clock tick.

The difference with kvm is smaller (just 3.9%), which is not easily explained as the time for the extra syscalls should be about the same. My guess is that guest behavior is different; with dynticks the guest does about twice as much work as with hpet.

Can you verify this by running

   strace -c -p `pgrep qemu` & sleep 10; pkill strace

for all 4 cases, and posting the results?


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]