Page MenuHomeFreeBSD

Remove excessive invalidations from pmap_remove().
AbandonedPublic

Authored by markj on Jan 3 2019, 7:55 PM.

Details

Summary

pmap_remove_l3() already performs the requisite invalidation. (This is
in contrast with amd64, where pmap_remove_ptes() only invalidates global
mappings.) In the long term it might be preferable to do what amd64
does, but for now just get rid of the extra code.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 21819
Build 21087: arc lint + arc unit

Event Timeline

markj created this revision.Jan 3 2019, 7:55 PM
markj edited the summary of this revision. (Show Details)Jan 3 2019, 8:10 PM
markj added reviewers: alc, kib, jhb, br, mhorne063_gmail.com.
kib accepted this revision.Jan 3 2019, 9:12 PM
This revision is now accepted and ready to land.Jan 3 2019, 9:12 PM
jhb accepted this revision.Jan 3 2019, 9:36 PM

On SMP systems the invalidate_range()'s here would seem to be more efficient since you can batch up the IPI's. I almost wonder if it wouldn't even be better to just do a single invalidate_range at the end instead of dealing with va_next and trying to be perfect about avoiding invalidation of ranges that weren't mapped. The only other call to pmap_remove_l3() in pmap_ts_referenced() is also followed by a call to pmap_invalidate_page(), so I wonder if removing pmap_invalidate_page() wouldn't be the better change?

markj abandoned this revision.Jan 4 2019, 5:59 PM
In D18730#399718, @jhb wrote:

On SMP systems the invalidate_range()'s here would seem to be more efficient since you can batch up the IPI's. I almost wonder if it wouldn't even be better to just do a single invalidate_range at the end instead of dealing with va_next and trying to be perfect about avoiding invalidation of ranges that weren't mapped. The only other call to pmap_remove_l3() in pmap_ts_referenced() is also followed by a call to pmap_invalidate_page(), so I wonder if removing pmap_invalidate_page() wouldn't be the better change?

(We discussed this further on #freebsd-riscv.) I agree and will hold off on this change; instead, following the superpage patches I'll change pmap_remove_l3() so that the caller handles invalidation. This will be part of a broader cleanup of pmap invalidation. RISC-V is a bit special in that we should perform a local TLB invalidation even after overwriting an invalid PTE: the implementation is permitted to cache invalid addresses, so a failure to issue an sfence.vma can result in a spurious fault following a pmap_enter(). We do handle such faults in pmap_fault_fixup(), but obviously it's preferable to avoid them in the first place.