Re: CVS commit: src/sys/arch/xen

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.migeon%free.fr@localhost