On Thu, Apr 20, 2017 at 02:00:55PM +0200, Paolo Bonzini wrote: > Hot path reqs_lock critical sections are very small; the only large critical > sections happen when a request waits for serialising requests, and these > should never happen in usual circumstances. > > We do not want these small critical sections to yield in any case, > which calls for using a spinlock while writing the list.
Is this patch purely an optimization? I'm hesitant about using spinlocks in userspace. There are cases where the thread is descheduled that are beyond our control. Nested virt will probably make things worse. People have been optimizing and trying paravirt approaches to kernel spinlocks for these reasons for years. Isn't a futex-based lock efficient enough? That way we don't hog the CPU when there is contention. Also, there are no performance results included in this patch that justify the spinlock.
signature.asc
Description: PGP signature
