When invalidating the entire TLB for a given pmap the operation can be
slow. Reduce this time by checking if the pmap is on the current asid
epoch, and only perform the invalidation if it is.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 43127 Build 40015: arc lint + arc unit
Event Timeline
This is in preparation for changing how to mark a pmap as dead in D30845. I'm planning on making the epoch INT_MAX for stage 2 pmaps in pmap_remove_pages so I can add an assertion on pmap_is_current_epoch(pmap) == false in the stage 2 case.
A version of this patch with the change described above included showed a statistically significant improvement on buildkernel times (over 5 runs), however I didn't reproduce with this version.
I do not fully understand the ASID mechanics for arm64, but what if we raced with the context switch and did not noticed allocation of asid in current epoch? Should this check be somehow interlocked with asid allocation?
In pmap_activate_int we have:
epoch = COOKIE_TO_EPOCH(pmap->pm_cookie); if (epoch >= 0 && epoch != set->asid_epoch) pmap_alloc_asid(pmap);
If we are within the update in pmap_reset_asid_set then set->asid_epoch will be -1. As long as epoch is at least 0 we will enter pmap_alloc_asid and wait on the asid set mutex. epoch == INT_MIN indicates an asid should never be allocated (There is no asid for the kernel, or a reserved asid, e.g. EFI).