qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC 0/4] memory: Fix (/ Discuss) a few rcu issues


From: David Hildenbrand
Subject: Re: [PATCH RFC 0/4] memory: Fix (/ Discuss) a few rcu issues
Date: Thu, 2 Mar 2023 10:46:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 25.02.23 17:31, Peter Xu wrote:
[not for merging, but for discussion; this is something I found when
  looking at another issue on Chuang's optimization for migration downtime]

Summary: we tried to access memory_listeners, address_spaces, etc. in RCU
way.  However we didn't implement them with RCU-safety. This patchset is
trying to do that; at least making it closer.

NOTE!  It's doing it wrongly for now, so please feel free to see this as a
thread to start discussing this problem, as in subject.

The core problem here is how to make sure memory listeners will be freed in
RCU ways, per when unlinking them from the global memory_listeners list.

Can you elaborate why we would want to do that? Is there a real reason we cannot hold the BQL when unregistering a listener?

Or could we use any other, more fine-grained, lock to protect the memory listeners?

Naive me would think that any interactions between someone updating the memory listeners, and a listener getting removed, would require some careful synchronization (to not rip a notifier out while someone else notifies -- what is the still registered notifier supposed to do with notifications while it is already going away?), instead of doing it via RCU.

I'm all for using RCU if it improves performance and keeps things simple. If RCU is neither required for performance reason and overcomplicates the implementation, maybe using locking is the better choice.

TBH, so far I thought that any memory_listeners register/unregistering *requires* the BQL, and everything else is a BUG.

--
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]