Hmm. PCPU_GET() calls get_pcpu() internally, which is implemented as cp15 operation in SMP case. And cp15 operations may be slow. As an optimalization, I suggest to use get_pcpu() here and use obtained pointer.

Further, I checked other related functions. They use pcpu_find() when current struct pcpu* is wanted. While pcpu_find() is a function which needs to get current CPU id (one cp15 operation) to get struct pcpu*, get_pcpu() is a macro which gets struct pcpu* (one cp15 operation) directly. So, I suggest to replace pcpu_find() by get_pcpu() in these functions in a different commit.

Thank you for reminding me that we have get_pcpu() on arm. That was what I really wanted to use on i386, but unfortunately we only have the thread pointer in %gs there. BTW, concern over relative slowness of %gs and cp15 access was exactly the reason I chose to use pcpu_find() in the other functions: https://reviews.freebsd.org/D8833?id=23041#inline-52317

%gs->%fs

To clarify my note. The following line is used to get current pcpu in the other functions:
pc = pcpu_find(curcpu);
where curcpu is defined as
#define curcpu PCPU_GET(cpuid)

Thus, pcpu_find(curcpu) can be broken down as:
(1) get current pcpu
(2) get current cpu id from current pcpu
(3) call pcpu_find()
(4) get current pcpu according to current cpu id.

So, steps (2),(3), and (4) are pointless.

I understood your original note, I noted the same thing while working on the i386 pmap.
Looking at the code for each architecture, I don't see why we can't add get_pcpu() for the other architectures besides arm/arm64/riscv where it currently exists. That might be of some benefit since there are quite a few places in MI code where we use the pcpu_find(curcpu) trick.

BTW, I decided to include the switch to get_pcpu() with this commit since the changes are few and $(WORK) is leaving me with little time to do more freebsd work this week.