[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 09:39:14PM +0200, Cherry G. Mathew wrote:
> JM> An alternative would be to have per-CPU xpq_queue also. This
> JM> is not completely stupid, xpq_queue is meant as a way to put
> JM> multiple MMU operations in a queue asynchronously before issuing
> JM> only one hypercall to handle them all.
> This is slightly more complicated than it appears. Some of the "ops" in
> a per-cpu queue may have ordering dependencies with other cpu queues,
> and I think this would be hard to express trivially. (an example would
> be a pte update on one queue, and reading the same pte read on another
> queue - these cases are quite analogous (although completely unrelated)
read don't go through the xpq queue, don't they ?
I think this is similar to a tlb flush but the other way round,
I guess we could use a IPI for this too.
> I'm thinking that it might be easier and more justifiable to nuke the
> current queue scheme and implement shadow page tables, which would fit
> more naturally and efficiently with CAS pte updates, etc.
I'm not sure this would completely fis the issue: with shadow page tables
you can't use a CAS to assure atomic operation with the hardware TLB, as
this is, precisely, a shadow PT and not the one used by hardware.
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |