On 24.03.2020 16:21, Hongyan Xia wrote: > From: Hongyan Xia <hongy...@amazon.com> > > Unfortunately, even though that commit dropped the domctl lock and > allowed other domctl to continue, it created severe lock contention > within domain destructions themselves. Multiple domain destructions in > parallel now spin for the global heap lock when freeing memory and could > spend a long time before the next hypercall continuation.
I'm not at all happy to see this reverted; instead I was hoping that we could drop the domctl lock in further cases. If a lack of continuations is the problem, did you try forcing them to occur more frequently? > In contrast, > after dropping that commit, parallel domain destructions will just fail > to take the domctl lock, creating a hypercall continuation and backing > off immediately, allowing the thread that holds the lock to destroy a > domain much more quickly and allowing backed-off threads to process > events and irqs. > > On a 144-core server with 4TiB of memory, destroying 32 guests (each > with 4 vcpus and 122GiB memory) simultaneously takes: > > before the revert: 29 minutes > after the revert: 6 minutes This wants comparing against numbers demonstrating the bad effects of the global domctl lock. Iirc they were quite a bit higher than 6 min, perhaps depending on guest properties. Jan
