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