On Mon, Feb 20, 2012 at 10:09:24AM -0800, Chuck Silvers wrote: > > > > 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. > > > > If the expensive call has to be made before updating the mappings, > > pmap_update() is not of that much use (or you have to remember operations > > to be made, and apply them at pmap_update() time, which is not that > > easy). > > since pmap_kremove() can defer its effects (though I guess it currently > doesn't > for xen, since otherwise your latest patch wouldn't work? not sure, I haven't > found the code yet), I would think we would need to call pmap_update() before > freeing the page in this code.
Right, for x86 (Xen or native) pmap_kremove writes the PTEs immediatly, but defer tlb invalidations. In case of Xen, tlb invalidations is done by the hypervisor if needed when reusing the page as PDP. > > if it's difficult to avoid calling pmap_update() multiple times due to that, > note that calling pmap_update() extra times doesn't have to cost very much, > since it can easily return without doing anything if no deferred operations > are pending. the x86 pmap_tlb_shootnow() already has a check for this, > though the x86 pmap_update() could be even cheaper in the case where it > really has nothing to do. I'm more concerned for cases where n*pmap_kremove() for one page costs a lot more than one pmap_kremove() for n pages. There are (non-x86) pmaps where this is the case, and collecting the data needed in pmap_kremove() to do it a pmap_update() time isn't cheap either. And if we go this way, the existing pmap_update() calls are not in the right place to make sure there's no write mapping behind when a page is freed ... -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
