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 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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index