Luca Tettamanti wrote:
Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
Actually I'm having troubles with cyclesoak (probably it's calibration),
numbers are not very stable across multiple runs...
I've had good results with
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.100.002966 0 96840 clock_gettime
19.500.001110 0 37050
On 8/22/07, Avi Kivity [EMAIL PROTECTED] wrote:
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.100.002966 0 96840
On 8/22/07, Luca [EMAIL PROTECTED] wrote:
I see a lot of sub ms timer_settime(). Many of them are the result of
-expire_time being less than the current qemu_get_clock().
False alarm, this was a bug in the debug code :D
Luca
On 8/22/07, Luca [EMAIL PROTECTED] wrote:
On 8/22/07, Avi Kivity [EMAIL PROTECTED] wrote:
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.10
On Wed, Aug 22, 2007 at 06:38:18PM +0200, Luca wrote:
and I'm reading it from /proc/config.gz on the guest.
And a huge number of settime calls?
Yes, maybe some QEMU timer is using an interval 1ms?
Dan do you any any idea of what's going on?
Not really...
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
-
---
52.100.002966 0 96840
clock_gettime
19.500.001110 0 37050
timer_gettime
On 8/22/07, Dor Laor [EMAIL PROTECTED] wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
-
---
52.100.002966 0 96840
clock_gettime
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
hpet4.8%
Avi Kivity ha scritto:
Luca Tettamanti wrote:
At 1000Hz:
QEMU
hpet5.5%
dynticks 11.7%
KVM
hpet3.4%
dynticks7.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
On Tue, 21 Aug 2007, Luca Tettamanti wrote:
Avi Kivity ha scritto:
Luca Tettamanti wrote:
At 1000Hz:
QEMU
hpet5.5%
dynticks 11.7%
KVM
hpet3.4%
dynticks7.3%
No surprises here, you can see the additional 1k syscalls per second.
This is very
Luca Tettamanti wrote:
Actually I'm having troubles with cyclesoak (probably it's calibration),
numbers are not very stable across multiple runs...
I've had good results with cyclesoak; maybe you need to run it in
runlevel 3 so the load generated by moving the mouse or breathing
doesn't
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
I think this is a really nice and important patch set. Just a couple
things:
On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it
should
work ok since this is the case without any dyn-tick.
Actually minimum resolution
Anthony Liguori wrote:
I think this is a really nice and important patch set. Just a couple
things:
On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this is the case without any dyn-tick.
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?
Luca
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
Hello,
in reply to this mail I will send a serie of 4 patches that cleans up
and
expands the alarm timer handling in QEMU. Patches have been rebased
on
QEMU
CVS.
Patch 1 is mostly a cleanup of the existing code; instead of having
multiple
#ifdefs to handle different timers scattered all
I think this is a really nice and important patch set. Just a couple
things:
On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this is the case without any dyn-tick.
Actually minimum resolution
19 matches
Mail list logo