Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events

[Paolo Bonzini <pbonzini@redhat.com>]

Il 09/10/2013 18:19, Alex Bligh ha scritto:
>> Do you also agree that the equivalent workaround, before
>> > Alex's patch, was MIN_REARM_TIMER_NS (and thus 250 microseconds)?
> I don't think this was the case, as if it's a timer constantly
> expiring we'd have seen select() exit as soon as it was entered
> by the fd poked by the signal.

The signal itself was clamped to be at least 250 microseconds...

> That might be far more frequent.

... it's true though that it could have been less than 250 microseconds
(more precisely, 250 microseconds minus the time from qemu_mod_timer_ns
to select).

Since the CPU usage with Hans's patch is 100% and used to be 50%, it was
also more than 1 ns that Hans's patch is using.

> I think the equivalent would be something like: if the 'zero'
> timeout comes from the deadline calculation (and not
> nonblocking=true) then release the lock anyway. I think
> that would be a reasonable approach.
> 
> I would however like to get to the bottom of what's causing
> this as even pre my changes playing sound was apparently taking
> 50% CPU, which is not good. I am completely packed until the
> weekend but I propose producing a timer debug patch which
> will instrument what is expiring constantly (unless the
> problem with spice is obvious to someone).

I think Hans already debugged it to the (supposedly) 33 Hz timer that
spice audio uses.

If it turns out the bug is in the QEMU part of spice, I think it makes
sense _not_ to include this patch at all.

If it turns out to be in spice itself, then we can include it as a
workaround, but still it would be nice to tune a bit the limit and not
burn even more CPU time than before.

Paolo