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