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: Alex Bligh
Subject: Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events
Date: Wed, 9 Oct 2013 14:18:19 +0100

On 9 Oct 2013, at 13:58, Hans de Goede wrote:

> I got an off-list email this morning from a kind soul informing me that
> he was seeing the same issue as me, but only when using audio over
> spice. I've just tried things with "-device hda -device hda-duplex"
> removed from my qemu cmdline and I can confirm this is the same for me.
> 
> There seem to be more cases which trigger the timer set to expire in the
> past case, I added a printf("bingo\n"); to my code for catching this
> case and still unlocking the lock there, and it triggers a couple of
> times before the hda device becomes active too.

OK, that's useful.

> As soon as pulseaudio starts in the guest the screen really starts
> filling with bingos though, so it definitely seems a spice + audio problem,
> 
> Normally the bingo's stop scrolling by after a couple of seconds (as pulse
> audio stops the audio device when there is no sound), but when I try to play
> music they keep scrolling.
> 
> Also playing music in git master (with my patch) makes qemu take 100% host 
> cpu,
> while doing the same using qemu-1.5.3 takes 50% host cpu, so there definetily
> is something wrong here.

Possibly in both cases!

> Looking at the spice code in question, we have the spice-server code
> setting a timer to go of every MM_TIMER_GRANULARITY_MS ms, which is every
> 33 ms, so not often at all.
> 
> Spice server does this by calling ui/spice-core.c timer_start() from its
> timer function, which does:
> 
> 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);

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

Or of course there might be a bug in the timer code.

> Note how it goes from the current time, not from some saved time, so even
> if we've missed a couple of timer ticks it should catch up with the
> current time after running once.

Sure. I would guess what's happening is that the timer is modified such
that it is already expired.

Alex

> 
> So long story short I've no idea what is going on here, and Alex is right
> that there is a bigger underlying problem.

-- 
Alex Bligh







reply via email to

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