[Top][All Lists]

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

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

From: malc
Subject: Re: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
Date: Tue, 21 Aug 2007 01:55:17 +0400 (MSD)

On Mon, 20 Aug 2007, Luca Tettamanti wrote:

Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti <address@hidden> 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

[..snip the numbers..]

After briefly looking at the cyclesoak it indeed looks like it does
the right thing, but considering the limitations of user-space only
approach it introduces some (sometimes really unwanted) variables
into the system, those can, and i guess will, influence things.

The upshot is this - if you have used any standard utility (iostat,
top - basically anything /proc/stat based) the accounting has a fair
chance of being inaccurate. If cyclesoak is what you have used then
the results should be better, but still i would be worried about

In conclusion until kernel native accounting is fixed your best bet
is to use: http://www.boblycat.org/~malc/apc/


reply via email to

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