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
>> > >>> This is QEMU, with dynticks and HPET:
>> > >>>
>> > >>> % time seconds usecs/call callserrors syscall
>> > >>> -- --- --- - -
-
>---
>> > >>> 52.100.002966 0 96840
clock_gettime
>> > >>> 19.500.001110
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...
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
> > >>> -- --- --- - - ---
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, 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
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
On 8/22/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> 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
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 goo
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 cyclesoak; maybe you need to run
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
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 surprising t
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.
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%
dynticks
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 <[EMAIL PROTECTED]> wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t nearest_delta_us = ULLONG_MAX;
+uint64_t vmdelta_us;
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,
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 introduc
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
Avi Kivity 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 depends on host HZ setting, but - yes -
> >>essentially you have the same behaviour of the "unix" tim
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.
>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 mini
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 resol
Dor Laor ha scritto:
> >> 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
> >multip
>> 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 s
24 matches
Mail list logo