Manuel Bouyer <[email protected]> wrote: > On Sat, Feb 18, 2012 at 10:12:36AM -0800, Chuck Silvers wrote: > > On Sat, Feb 18, 2012 at 07:01:24PM +0100, Manuel Bouyer wrote: > > > > - the calls to pmap_update() should be moved along with the calls > > > > to pmap_kremove(). > > > > > > But not all pmap_kremove() are followed by a pmap_update() in the > > > initial code. Is it a bug ? > > > > yes. we don't currently defer TLB invalidations from pmap_kremove() on > > x86 (or probably any platform), but if we start doing that then the > > pmap_update()s are needed. > > Note that some places are doing the pmap_update(), but not immediatly > after uvm_km_pgremove_intrsafe(). By adding a pmap_update() in > uvm_km_pgremove_intrsafe() we may be doing it twice. > > I've added pmap_update() to uvm_km_pgremove_intrsafe() and removed > pmap_update() calls that were immedialy following a > uvm_km_pgremove_intrsafe. > > I also implemented the idea of removing the mappings and freeing page > in batch of 16 entries. Updated patch attached, I'm re-running the > build.sh -jx release tests. This should also fix the problem in the native > case as there's no #ifdef any more :)
This is unnecessary (due to deferred invalidations), please keep it simple. Note that the expensive TLB flushes is the reason why optimisations like here exist: http://nxr.netbsd.org/xref/src/sys/uvm/uvm_map.c#2310 P.S. During rmind-uvmplock branch work, I checked all pmap_[k]remove() cases, that they have pmap_update() and there are no race conditions, so we should be fine. -- Mindaugas
