On Thu, May 04, 2017 at 06:06:39PM +0200, Paolo Bonzini wrote: > On 04/05/2017 16:59, Stefan Hajnoczi wrote: > > 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? > > Yes, it is, and pretty much a no-op until we have true multiqueue. But > I expect it to have a significant effect for multiqueue. > > > 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. > > This is true, but here we're talking about a 5-10 instruction window for > preemption; it matches the usage of spinlocks in other parts of QEMU.
Only util/qht.c uses spinlocks, it's not a widely used primitive. > The long critical sections, which only happen with combination with > copy-on-read or RMW (large logical block sizes on the host), take the > CoMutex. > > On one hand it's true that the more you nest, the more things get worse. > On the other hand there can only ever be contention with multiqueue, > and the multiqueue scenarios are going to use pinning. > > > Isn't a futex-based lock efficient enough? That way we don't hog the > > CPU when there is contention. > > It is efficient when there is no contention, but when there is, the > latency goes up by several orders of magnitude. Doesn't glibc spin for a while before waiting on the futex? i.e. the best of both worlds. Stefan
signature.asc
Description: PGP signature