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. -- Jean-Yves Migeon jeanyves.mig...@free.fr