On 2025/10/20 15:38, Paolo Bonzini wrote:
On 10/16/25 21:33, Dmitry Osipenko wrote:
On 10/16/25 09:34, Akihiko Odaki wrote:
- /* Wait for one thread to report a quiescent state and try
again.
+ /*
+ * Sleep for a while and try again.
* Release rcu_registry_lock, so rcu_(un)register_thread()
doesn't
* wait too much time.
*
@@ -133,7 +150,20 @@ static void wait_for_readers(void)
* rcu_registry_lock is released.
*/
qemu_mutex_unlock(&rcu_registry_lock);
- qemu_event_wait(&rcu_gp_event);
+
+ if (forced) {
+ qemu_event_wait(&rcu_gp_event);
+
+ /*
+ * We want to be notified of changes made to rcu_gp_ongoing
+ * while we walk the list.
+ */
+ qemu_event_reset(&rcu_gp_event);
+ } else {
+ g_usleep(10000);
+ sleeps++;
Thanks a lot for this RCU improvement. It indeed removes the hard stalls
with unmapping of virtio-gpu blobs.
Am I understanding correctly that potentially we will be hitting this
g_usleep(10000) and stall virtio-gpu for the first ~10ms?
Would it help to have some kind of exponential backoff, starting with
1-3 ms and increasing after the first wait? Something like
1.5/3/6/12/12/12 ms would have a similar effect but reduce the wait if
the vCPU kick is fast enough.
vCPU kick is needed only for TCG and triggered with force_rcu when
entering the force quiescent state. The state is entered only after
finishing all polling checks, so shortening only the early ones may not
be effective for TCG.
It also increases the overhead for users other than virtio-gpu. I
suppose the first 10 ms sleep is sufficient for the most case, which
minimizes context switching due to sleep/wakeup. However, it is more
likely that a few of the early sleeps and their wakeups will be
triggered if they are shortened.
Now I'm thinking of adding an RCU API to request the force quiescent
state for virtio-gpu. It will be able to utilize the force quiescent
state (particularly for TCG) and is zero cost unless virtio-gpu is used.
Regards,
Akihiko Odaki
