Manuel Bouyer <[email protected]> wrote: > On Sat, Feb 18, 2012 at 07:49:13PM +0000, Mindaugas Rasiukevicius wrote: > > > [...] > > > 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. > > I guess it's the batch'ing of pmap_kremove that's unecessery. > I'm not sure: some pmap_kremove() implementation do what looks like > expensive calls (like PMAP_SYNC_ISTREAM_KERNEL on alpha, > pmap_vac_me_harder() on arm, VAC flushing on m68k/motorola, and so on). > Also, some platforms zero out pte using memset, and it's probably more > efficient than zeroing one at a time
Yes. Such architectures are free to follow performance improvements made on x86 and MIPS. It is the reason why we have pmap_update() in pmap(9) API. Also, for many architectures and older CPUs TLB flushes are not that expensive as in e.g. modern x86. > > 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. > > So should I move the pmap_update() back ? Yes, please. Thanks! -- Mindaugas
