On Mon, Nov 08, 2010 at 03:22:42PM +0000, Eduardo Horvath wrote: > On Mon, 8 Nov 2010, Masao Uebayashi wrote: > > > On Fri, Nov 05, 2010 at 05:36:53PM +0000, Eduardo Horvath wrote: > > > On Fri, 5 Nov 2010, Masao Uebayashi wrote: > > > > > > > On Mon, Nov 01, 2010 at 03:52:11PM -0700, Matt Thomas wrote: > > > > > > > > Indeed. Also consider that pmap's are designed to have to have > > > > > fast V->P translations, using that instead of UVM makes a lot of > > > > > sense. > > > > > > > > How does locking works? > > > > > > > > My understanding is page tables (per-process) are protected by > > > > struct vm_map (per-process). (Or moving toward it.) > > > > > > No, once again this is MD. For instance sparc64 uses compare and swap > > > instructions to manipulate page tables for lockless synchronization. > > > > I don't like "it's MD, period" attitude. That solves nothing. > > Yes it does. If you have bleed through between the different abstraction > layers it makes implementing a pmap for a new processor much more > difficult and makes the code inefficient since you end up implementing a > whole bunch of goo just to keep the sideffects compatible. You should not > be making any implicit assumptions beyond what is explicitly documented in > the interface descriptions otherwise the code becomes unmaintainable > across the dozens of different processors and MMU archittures we're trying > to support.
Most of pmaps are already almost unmaintainable IMO. ;)