qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when ma


From: Hans de Goede
Subject: Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events
Date: Wed, 09 Oct 2013 20:03:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

Hi,

On 10/09/2013 03:18 PM, Alex Bligh wrote:

<snip>

qemu_mod_timer(timer->timer, qemu_get_clock_ms(rt_clock) + ms);

qemu_mod_timer does not exist in master.

This line is now:

     timer_mod(timer->timer, qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + ms);

Ah yes my bad, I was accidentally looking at a stable-1.5 checkout.

This suggests to me either timer->scale is not set to 1000000 (i.e.
it isn't in milliseconds),

The timer always gets created like this:

    timer->timer = timer_new_ms(QEMU_CLOCK_REALTIME, func, opaque);

OR ms is zero/negative.

Nope I've added a debug printf to the spice timer code and it all works
as expected.

So I started looking for suspecious timers under audio/*.c and immediately
found this in audio/audio.c :

static void audio_reset_timer (AudioState *s)
{
    if (audio_is_timer_needed ()) {
        timer_mod (s->ts, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 1);
    }
    else {
        timer_del (s->ts);
    }
}

static void audio_timer (void *opaque)
{
    audio_run ("timer");
    audio_reset_timer (opaque);
}

Note how that is using a timer which expires every freaking nano second,
I think it is very likely that is the culprit.

Regards,

Hans



reply via email to

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