Re: Fio regression caused by f9fc8932b11f3bcf2a2626f567cb6fdd36a33a94

[Paolo Bonzini]

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:

20220505131346.823941-1-pbonzini@redhat.com/raw">https://lore.kernel.org/qemu-devel/20220505131346.823941-1-pbonzini@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