On Sun, Aug 21, 2011 at 12:38:06PM +0200, Jean-Yves Migeon wrote: > On 21.08.2011 12:26, Jean-Yves Migeon wrote: > > - second, the lock is not placed at the correct abstraction level IMHO, > > it is way too high in the caller/callee hierarchy. It should remain > > hidden from most consumers of the xpq_queue API, and should only be used > > to protect the xpq_queue array together with its counters (and > > everything that isn't safe for all memory operations happening in xpq). > > > > Reason behind this is that your lock protects calls to hypervisor MMU > > operations, which are hypercalls (hence, a "slow" operation with regard > > to kernel). You are serializing lots of memory operations, something > > that should not happen from a performance point of view (some may take a > > faire amount of cycles to complete, like TLB flushes). I'd expect all > > Xen MMU hypercalls to be reentrant. > > An alternative would be to have per-CPU xpq_queue[] also. This is not > completely stupid, xpq_queue is meant as a way to put multiple MMU > operations in a queue asynchronously before issuing only one hypercall > to handle them all.
Sure, this is the way to go. -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
