On 5/5/22 14:44, Daniel P. Berrangé wrote:
util/thread-pool.c uses qemu_sem_*() to notify worker threads when work
becomes available. It makes sense that this operation is
performance-critical and that's why the benchmark regressed.
Doh, I questioned whether the change would have a performance impact,
and it wasn't thought to be used in perf critical places
The expectation was that there would be no contention and thus no
overhead because of the pool->lock that exists anyway, but that was
optimistic.
Lukáš, can you run a benchmark with this condvar implementation that was
suggested by Stefan:
https://lore.kernel.org/qemu-devel/20220505131346.823941-1-pbonz...@redhat.com/raw
?
If it still regresses, we can either revert the patch or look at a
different implementation (even getting rid of the global queue is an
option).
Thanks,
Paolo
