Page MenuHomeFreeBSD

Remove excessive invalidations from pmap_remove().
AbandonedPublic

Authored by markj on Jan 3 2019, 7:55 PM.
Tags
None
Referenced Files
F81636511: D18730.diff
Fri, Apr 19, 7:33 AM
Unknown Object (File)
Feb 10 2024, 3:31 AM
Unknown Object (File)
Dec 20 2023, 3:29 AM
Unknown Object (File)
Dec 8 2023, 7:48 PM
Unknown Object (File)
Aug 24 2023, 3:04 AM
Unknown Object (File)
Jul 30 2023, 11:29 PM
Unknown Object (File)
Jul 3 2023, 8:10 AM
Unknown Object (File)
May 10 2023, 9:56 PM
Subscribers
None

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 Passed
Unit
No Test Coverage
Build Status
Buildable 21819
Build 21087: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jan 3 2019, 9:12 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?

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.