From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] rcu: Unify force quiescent state
Date: Sun, 19 Oct 2025 23:25:14 +0300 [thread overview]
Message-ID: <91a97184-94c8-4b55-99a6-05a0dc4142b1@collabora.com> (raw)
In-Reply-To: <20251016-force-v1-1-919a82112498@rsg.ci.i.u-tokyo.ac.jp>
On 10/16/25 09:34, Akihiko Odaki wrote:
> Borrow the concept of force quiescent state from Linux to ensure readers
> remain fast during normal operation and to avoid stalls.
>
> Background
> ==========
>
> The previous implementation had four steps to begin reclamation.
>
> 1. call_rcu_thread() would wait for the first callback.
>
> 2. call_rcu_thread() would periodically poll until a decent number of
> callbacks piled up or it timed out.
>
> 3. synchronize_rcu() would statr a grace period (GP).
>
> 4. wait_for_readers() would wait for the GP to end. It would also
> trigger the force_rcu notifier to break busy loops in a read-side
> critical section if drain_call_rcu() had been called.
>
> Problem
> =======
>
> The separation of waiting logic across these steps led to suboptimal
> behavior:
>
> The GP was delayed until call_rcu_thread() stops polling.
>
> force_rcu was not consistently triggered when call_rcu_thread() detected
> a high number of pending callbacks or a timeout. This inconsistency
> sometimes led to stalls, as reported in a virtio-gpu issue where memory
> unmapping was blocked[1].
>
> wait_for_readers() imposed unnecessary overhead in non-urgent cases by
> unconditionally executing qatomic_set(&index->waiting, true) and
> qemu_event_reset(&rcu_gp_event), which are necessary only for expedited
> synchronization.
>
> Solution
> ========
>
> Move the polling in call_rcu_thread() to wait_for_readers() to prevent
> the delay of the GP. Additionally, reorganize wait_for_readers() to
> distinguish between two states:
>
> Normal State: it relies exclusively on periodic polling to detect
> the end of the GP and maintains the read-side fast path.
>
> Force Quiescent State: Whenever expediting synchronization, it always
> triggers force_rcu and executes both qatomic_set(&index->waiting, true)
> and qemu_event_reset(&rcu_gp_event). This avoids stalls while confining
> the read-side overhead to this state.
>
> This unified approach, inspired by the Linux RCU, ensures consistent and
> efficient RCU grace period handling and confirms resolution of the
> virtio-gpu issue.
>
> [1] https://lore.kernel.org/qemu-devel/20251014111234.3190346-9-alex.bennee@linaro.org/
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> util/rcu.c | 79 ++++++++++++++++++++++++++++++++++++++++----------------------
> 1 file changed, 51 insertions(+), 28 deletions(-)
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # drm native
contexts + venus
--
Best regards,
Dmitry
prev parent reply other threads:[~2025-10-19 20:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 6:34 [PATCH] rcu: Unify force quiescent state Akihiko Odaki
2025-10-16 12:59 ` Paolo Bonzini
2025-10-16 19:33 ` Dmitry Osipenko
2025-10-16 23:43 ` Akihiko Odaki
2025-10-17 0:40 ` Akihiko Odaki
2025-10-19 20:23 ` Dmitry Osipenko
2025-10-20 1:14 ` Akihiko Odaki
2025-10-20 20:41 ` Dmitry Osipenko
2025-10-22 3:30 ` Dmitry Osipenko
2025-10-23 5:50 ` Akihiko Odaki
2025-10-23 9:50 ` Dmitry Osipenko
2025-10-20 6:38 ` Paolo Bonzini
2025-10-21 4:14 ` Akihiko Odaki
2025-10-19 20:25 ` Dmitry Osipenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=91a97184-94c8-4b55-99a6-05a0dc4142b1@collabora.com \
--to=dmitry.osipenko@collabora.com \
--cc=armbru@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).