|
From: | Paolo Bonzini |
Subject: | Re: Fio regression caused by f9fc8932b11f3bcf2a2626f567cb6fdd36a33a94 |
Date: | Thu, 5 May 2022 15:27:56 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |