powerpc64: initial conversion of oea64 to rwlocks

[adrian]

Summary

• convert part of the oea64 mmu code to rwlocks.
• change the pv lock names to individual ones for analysing hotspots.
• create a lock acquisition/free pattern based on radix mmu / amd64 pmap.
• migrate pmap_enter, pmap_enter_object and its downstream callers over to use this.
• Enable rwlock recursion on writers, since the superpage code hasn't yet been converted and i'm seeing lock recursion happen in this path.
• convert pvo cleanup to use the lock iterator.

This means that the pv lock is held for a bit longer, but I audited the
spots and it looks OK and isn't yet tripping up witness in a 4 CPU VM.

[adrian]

This is sort of WIP - there's some TODOs in here. I'd like some feedback on the locking changes and whether I missed something. Thanks!

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

130

If PV lock should be by superpage, the shift should be 24, because super pages are 16MB. I wonder if that might reduce contention a bit. Since the lock would then cover the full 16MB instead of needing 8 separate locks, you may be able to simply lock once to iterate over the full super page.

[kib]

sys/powerpc/aim/mmu_oea64.c

130

On amd64 the lock must be per super-page. Demotions and promotions depend on this, they need to manipulate pv entries for all pages that constitute the superpage. This is not an optimization to reduce contention, but the fundamental feature.

I do not know if this holds for powerpc pmaps, but I highly suspect that it does.

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

130

You're very likely correct on this. When @luporl wrote the superpage code he probably missed this, and so did I in the review. That may explain some of the complexity in the superpage code.

[adrian]

sys/powerpc/aim/mmu_oea64.c

130

errr...

hw.pagesizes: { 4096, 2097152 }

that's on a power9 vm, and my power8 powernv shows the same thing.

So we're doing 2mb superpages, so that shift looks right!

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

130

It's a lie. 2MB superpages are only on radix pmap. This needs to be fixed for HPT, which only supports 16MB superpages.

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

130

I don't see how you could see 2097152 for HPT, because moea64_early_bootstrap() sets vm_level_0_order to 12 immediately, before it sets the pagesizes array. Something is screwy.

[adrian]

sys/powerpc/aim/mmu_oea64.c

130

ah no, it /is/ 16mb superpages on the hash table.

i'll ask markj about this in a bit more detail.

[adrian]

rebase after jhibbits@ recent changes