Batch v_wire_count updates in the pmap code.

[markj]

Summary

Atomic updates to v_wire_count are a significant source of contention,
so help reduce this by decrementing v_wire_count only once when freeing
a set of page table pages.

[kib]

sys/amd64/amd64/pmap.c

2215 ↗

(On Diff #31364)

for (count = 0; ((m = SLIST_FIRST()) != NULL; count++) {} ?

[alc]

sys/amd64/amd64/pmap.c

2331 ↗

(On Diff #31364)

Is sending an IPI a serializing operation? If so, then doesn't every possible method of TLB invalidation contain at least one serializing operation? If that's the case, then this seems pointless.

I think that a comment at the head of the TLB invalidation functions about their serializing effects would be better.

[kib]

sys/amd64/amd64/pmap.c

2331 ↗

(On Diff #31364)

What do you mean by pointless ? The rel fence above or the whole change ? rel is only a compiler barrier.

That said, sending IPI (as opposed to act on IPI) is not obligatory serializing. I added mfence to x2APIC-mode IPI-send to be compatible with xAPIC mode, since there was some code depending on the effects before IPI visible to IPI handler. But this is not enforced by hardware and might be optimized to avoid fence if possible.

[alc]

sys/amd64/amd64/pmap.c

2331 ↗

(On Diff #31364)

The rel fence above or the whole change ?

Just the release fence. I'm questioning whether we shouldn't just remove this whole snippet. (There is also the inherent ordering of stores on the x86 to consider.)

Otherwise, I like the change.

[alc]

sys/amd64/amd64/pmap.c

2331 ↗

(On Diff #31364)

Just an observation ... This release fence is inherited from the i386 pmap, where it is immediately followed by a TLB invalidation on the recursive mapping.

[markj]

Address review feedback:

• Use a for-loop in pmap_free_zero_pages().
• Remove fences in _pmap_unwire_ptp(). While ipi_cpu() is not necessarily serializing, x86 has TSO.