Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
> Luca wrote:
> > On 8/19/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >
> >> +static uint64_t qemu_next_deadline(void) {
> >> + uint64_t nearest_delta_us = ULLONG_MAX;
> >> + uint64_t vmdelta_us;
> >>
> >
> > Hum, I introduced a bug here... those vars should be signed.
> >
> > On the overhead introduced: how do you measure it?
> >
> >
>
> 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.
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. On
the bright side, keep in mind that with a tickless guest and dynticks
I've seen as little as 50-60 timer ticks per second.
Hackbench (hackbench -pipe 50) inside the guest:
QEMU: impossible to measure, the variance of the results is much bigger
than difference between dynticks and hpet.
KVM:
Around 0.8s slower in case on dynticks; variance of the results is
about 0.3s in both cases.
Luca
--
"Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi"
Sun Tzu -- L'arte della guerra
