Details

Reviewers

markj
mhorne

Group Reviewers

riscv

Commits

rG99360212c739: riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_range

Summary

This change introduces a variant of pmap_invalidate_range that uses
the fine-grained TLB invalidation instructions introduced by the
Svinval extension. These instructions allow for more efficient TLB
flushing on certain implementations. Under this new scheme,
pmap_invalidate_range was converted to an ifunc that selects the
appropriate variant during boot.

Event: BSDCan 2026

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 73949
Build 70832: arc lint + arc unit

Event Timeline

bnovkov created this revision.Jun 17 2026, 9:23 PM

Herald added a subscriber: imp. · View Herald TranscriptJun 17 2026, 9:23 PM

bnovkov requested review of this revision.Jun 17 2026, 9:23 PM

Harbormaster completed remote builds in B73949: Diff 179962.Jun 17 2026, 9:23 PM

bnovkov added a parent revision: D57623: riscv: Add support for the Svinval extension.Jun 17 2026, 9:24 PM

mhorne accepted this revision.Jun 24 2026, 2:03 PM

mhorne added a subscriber: mhorne.

mhorne added inline comments.

sys/riscv/riscv/pmap.c
1121–1122

This revision is now accepted and ready to land.Jun 24 2026, 2:03 PM

mhorne added inline comments.Jun 24 2026, 2:06 PM

sys/riscv/riscv/pmap.c
1108	The relationship between this check and the definition above was a momentary confusion for me. You might do away with the `atop()` and `PAGE_SIZE` division altogether.

Why not use this for pmap_invalidate_page() as well?

Address @markj 's and @mhorne 's comments:

add an svinval-aware pmap_invalidate_page variant
remove awkward atop conversion

This revision now requires review to proceed.Jul 5 2026, 12:45 PM

mhorne accepted this revision.Jul 9 2026, 5:21 PM

This revision is now accepted and ready to land.Jul 9 2026, 5:21 PM

markj added inline comments.Jul 13 2026, 2:45 PM

sys/riscv/riscv/pmap.c
1171	Why is this done in the callback? Shouldn't we just fall back to a direct pmap_invalidate_all() call?
1194	I think you want to pass `smp_no_rendezvous_barrier` instead of NULL here, otherwise all CPUs will needlessly synchronize before invoking the callback, and again after. See smp_rendezvous_action().

Address @markj 's comments

This revision now requires review to proceed.Jul 13 2026, 6:20 PM

Harbormaster completed remote builds in B74776: Diff 181919.Jul 13 2026, 6:20 PM

bnovkov marked 2 inline comments as done.Jul 13 2026, 6:22 PM

bnovkov added inline comments.

sys/riscv/riscv/pmap.c
1171	No particular reason, it seemed like the most straightforward solution at the time. I have no preferences here, I've worked your suggestion into the patch.

markj added inline comments.Jul 13 2026, 6:24 PM

sys/riscv/riscv/pmap.c
1193	Why exactly do we need this fence? Is it just copied from the SBI implementation?
1199	So above we invoked the callback on all harts except this one, waiting for them to finish, and now we're doing the invalidation on the current hart. Why not do them all in parallel?

bnovkov marked an inline comment as done.Jul 13 2026, 7:37 PM

bnovkov added inline comments.

sys/riscv/riscv/pmap.c
1193	The fence here follows the convention outlined in the comment above `pmap_invalidate_page_sbi`, which was introduced back in D17414. I assume it's here because `sfence_vma`s that target an address only apply to the leaf PTEs, but I'm not sure.
1199	Right, that pattern only makes sense in the sbi_* variants where I assume we want to avoid calling into openSBI. I'll include the original cpu in the mask as well.

Avoid clearing CPU mask for range invalidation

Harbormaster completed remote builds in B74799: Diff 181986.Jul 14 2026, 6:48 PM

Did you microbenchmark the new implementation? I'd be curious to know, say, how many cycles it takes to execute 10000 back-to-back 4KB page invalidations using the old and new implementations respectively, when the target CPU mask is just the current CPU and when it's the set of all CPUs.

This revision is now accepted and ready to land.Jul 15 2026, 2:01 PM

Closed by commit rG99360212c739: riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_range (authored by bnovkov). · Explain WhyMon, Aug 10, 4:02 PM

This revision was automatically updated to reflect the committed changes.

bnovkov added a commit: rG99360212c739: riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_range.

In D57624#1336128, @markj wrote:

Did you microbenchmark the new implementation? I'd be curious to know, say, how many cycles it takes to execute 10000 back-to-back 4KB page invalidations using the old and new implementations respectively, when the target CPU mask is just the current CPU and when it's the set of all CPUs.

Unfortunately no, I haven't had the time to run a proper microbenchmark yet.

riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_range
ClosedPublic
Actions

Details

Diff Detail

Event Timeline

Revision Contents
Changeset List

Diff 179962

sys/riscv/riscv/pmap.c

riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_rangeClosedPublicActions

Details

Diff Detail

Event Timeline

Revision ContentsChangeset List

Diff 179962

sys/riscv/riscv/pmap.c

riscv/pmap.c: Add an Svinval-aware variant of pmap_invalidate_range
ClosedPublic
Actions

Revision Contents
Changeset List