[PATCH v2 0/6] virtio-gpu: Force RCU when unmapping blob

Akihiko Odaki posted 6 patches 1 month, 4 weeks ago
Failed in applying to current master (apply log)
There is a newer version of this series
include/qemu/futex.h              | 34 ++++++++++++--
include/qemu/rcu.h                |  1 +
include/qemu/thread-posix.h       | 11 +++++
include/qemu/thread.h             |  8 +++-
include/qemu/timer.h              |  4 +-
hw/display/virtio-gpu-virgl.c     |  1 +
tests/unit/test-aio-multithread.c |  2 +-
util/event.c                      | 28 +++++++++--
util/main-loop.c                  |  2 +-
util/qemu-thread-posix.c          | 11 +----
util/qemu-timer.c                 |  7 +--
util/rcu.c                        | 98 ++++++++++++++++++++++-----------------
12 files changed, 137 insertions(+), 70 deletions(-)
[PATCH v2 0/6] virtio-gpu: Force RCU when unmapping blob
Posted by Akihiko Odaki 1 month, 4 weeks ago
Unmapping a blob changes the memory map, which is protected with RCU.
RCU is designed to minimize the read-side overhead at the cost of
reclamation delay. While this design usually makes sense, it is
problematic when unmapping a blob because the operation blocks all
virtio-gpu commands and causes perceivable disruption.

Minimize such the disruption with force_rcu(), which minimizes the
reclamation delay at the cost of a read-side overhead.

Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
Changes in v2:
- Stopped overloading the call_rcu1() and force_rcu() notifications onto
  one event. This fixes a deadlock after try_dequeue() caused by
  incorrect masking of call_rcu1() notifications, and eliminates
  spurious force quiescent states caused by being confused with a
  call_rcu1() notification.
  Tested-by: from the previous version was not collected because this
  changes the logic significantly.
- Merged the rcu_call_count and forced variables into one to avoid
  the race between them that used to require a loop to resolve.
- Aligned the type of the duration variable in qemu_futex_timedwait()
  for Windows.
- Fixed timespec of qemu_futex_timedwait() for 32-bit Linux.
- Link to v1: https://lore.kernel.org/qemu-devel/20251029-force_rcu-v1-0-bf860a6277a6@rsg.ci.i.u-tokyo.ac.jp

---
Akihiko Odaki (6):
      timer: Rename init_clocks() to qemu_clock_init()
      futex: Add qemu_futex_timedwait()
      qemu-thread: Add qemu_event_timedwait()
      rcu: Use call_rcu() in synchronize_rcu()
      rcu: Wake the RCU thread when draining
      virtio-gpu: Force RCU when unmapping blob

 include/qemu/futex.h              | 34 ++++++++++++--
 include/qemu/rcu.h                |  1 +
 include/qemu/thread-posix.h       | 11 +++++
 include/qemu/thread.h             |  8 +++-
 include/qemu/timer.h              |  4 +-
 hw/display/virtio-gpu-virgl.c     |  1 +
 tests/unit/test-aio-multithread.c |  2 +-
 util/event.c                      | 28 +++++++++--
 util/main-loop.c                  |  2 +-
 util/qemu-thread-posix.c          | 11 +----
 util/qemu-timer.c                 |  7 +--
 util/rcu.c                        | 98 ++++++++++++++++++++++-----------------
 12 files changed, 137 insertions(+), 70 deletions(-)
---
base-commit: 466e779e05b5087bffe39ecc51ec97fdf9121e8b
change-id: 20251027-force_rcu-616c743373f7

Best regards,
--  
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Re: [PATCH v2 0/6] virtio-gpu: Force RCU when unmapping blob
Posted by Dmitry Osipenko 1 month ago
On 12/13/25 08:41, Akihiko Odaki wrote:
> Unmapping a blob changes the memory map, which is protected with RCU.
> RCU is designed to minimize the read-side overhead at the cost of
> reclamation delay. While this design usually makes sense, it is
> problematic when unmapping a blob because the operation blocks all
> virtio-gpu commands and causes perceivable disruption.
> 
> Minimize such the disruption with force_rcu(), which minimizes the
> reclamation delay at the cost of a read-side overhead.
> 
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> Changes in v2:
> - Stopped overloading the call_rcu1() and force_rcu() notifications onto
>   one event. This fixes a deadlock after try_dequeue() caused by
>   incorrect masking of call_rcu1() notifications, and eliminates
>   spurious force quiescent states caused by being confused with a
>   call_rcu1() notification.
>   Tested-by: from the previous version was not collected because this
>   changes the logic significantly.
> - Merged the rcu_call_count and forced variables into one to avoid
>   the race between them that used to require a loop to resolve.
> - Aligned the type of the duration variable in qemu_futex_timedwait()
>   for Windows.
> - Fixed timespec of qemu_futex_timedwait() for 32-bit Linux.
> - Link to v1: https://lore.kernel.org/qemu-devel/20251029-force_rcu-v1-0-bf860a6277a6@rsg.ci.i.u-tokyo.ac.jp
> 
> ---
> Akihiko Odaki (6):
>       timer: Rename init_clocks() to qemu_clock_init()
>       futex: Add qemu_futex_timedwait()
>       qemu-thread: Add qemu_event_timedwait()
>       rcu: Use call_rcu() in synchronize_rcu()
>       rcu: Wake the RCU thread when draining
>       virtio-gpu: Force RCU when unmapping blob
> 
>  include/qemu/futex.h              | 34 ++++++++++++--
>  include/qemu/rcu.h                |  1 +
>  include/qemu/thread-posix.h       | 11 +++++
>  include/qemu/thread.h             |  8 +++-
>  include/qemu/timer.h              |  4 +-
>  hw/display/virtio-gpu-virgl.c     |  1 +
>  tests/unit/test-aio-multithread.c |  2 +-
>  util/event.c                      | 28 +++++++++--
>  util/main-loop.c                  |  2 +-
>  util/qemu-thread-posix.c          | 11 +----
>  util/qemu-timer.c                 |  7 +--
>  util/rcu.c                        | 98 ++++++++++++++++++++++-----------------
>  12 files changed, 137 insertions(+), 70 deletions(-)
> ---
> base-commit: 466e779e05b5087bffe39ecc51ec97fdf9121e8b
> change-id: 20251027-force_rcu-616c743373f7
> 
> Best regards,
> --  
> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> 

The first patch renaming init_clocks() doesn't apply to latest staging
branch because there is a similar change there, so I skipped it. Tested
with venus and drm-native contexts, no problems found.

Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

-- 
Best regards,
Dmitry