Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

Home | Main Index | Thread Index | Old Index