|
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 guest.
[..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 them. In conclusion until kernel native accounting is fixed your best bet is to use: http://www.boblycat.org/~malc/apc/ -- vale
[Prev in Thread] | Current Thread | [Next in Thread] |