Page MenuHomeFreeBSD

powerpc: Improve pvo allocation code
ClosedPublic

Authored by luporl on Jul 23 2019, 1:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 24, 8:49 PM
Unknown Object (File)
Oct 22 2024, 7:10 PM
Unknown Object (File)
Oct 4 2024, 12:01 PM
Unknown Object (File)
Sep 28 2024, 6:10 PM
Unknown Object (File)
Sep 28 2024, 2:45 AM
Unknown Object (File)
Sep 27 2024, 2:44 PM
Unknown Object (File)
Sep 22 2024, 11:21 PM
Unknown Object (File)
Sep 20 2024, 10:23 PM
Subscribers

Details

Summary

Added allocation retry loop in alloc_pvo_entry(), to wait for
memory to become available if the caller specifies the M_WAITOK flag.

Also, the loop in moa64_enter() was removed, as moea64_pvo_enter()
never returns ENOMEM. It is alloc_pvo_entry() memory allocation that
can fail and must be retried.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/powerpc/aim/mmu_oea64.c
1411 ↗(On Diff #60041)

Unfortunately, the "flags & PMAP_ENTER_NOSLEEP? M_NOWAIT : M_WAITOK" approach didn't work.
It results in a lot WITNESS warnings about sleeping with a non-sleepable lock held (kernel rw object).
That's why I'm forcing M_NOWAIT here.

That raises the question: is there any other part of mmu code that can sleep in alloc_pvo_entry()? If not, then the wait loop in it won't make sense a should be removed.

sys/powerpc/aim/mmu_oea64.c
1411 ↗(On Diff #60041)

It's actually (kernel vm object), and the warning comes from uma_zalloc:

uma_zalloc_arg: zone "UPVO entry" with the following non-sleepable locks held:
exclusive rw kernel vm object (kernel vm object) r = 0 (0xc000000002fb6b08) locked @ /usr/src/sys/vm/vm_ke$
n.c:473
stack backtrace:
#0 0xc000000001fd25d0 at ??+0
#1 0xc000000001fd38f8 at ??+0
#2 0xc0000000022cfa74 at ??+0
#3 0xc00000000232b380 at ??+0
#4 0xc00000000232ad04 at ??+0
#5 0xc00000000236dabc at ??+0
#6 0xc0000000022de708 at ??+0
#7 0xc0000000022de430 at ??+0
#8 0xc0000000022d6450 at ??+0
#9 0xc0000000022d337c at ??+0
#10 0xc0000000022d67fc at ??+0
#11 0xc0000000022d1838 at ??+0
#12 0xc0000000022cf2b8 at ??+0
#13 0xc000000001f11510 at ??+0
#14 0xc000000001eb81d0 at ??+0
#15 0xc0000000019401cc at ??+0

jhibbits added inline comments.
sys/powerpc/aim/mmu_oea64.c
400 ↗(On Diff #60041)

This vm_wait() is unnecessary here. M_WAITOK in flags will wait until pvo can be !NULL.

It can be reduced to

else
   pvo = uma_zalloc(moea64_pvo_zone, flags | M_ZERO);
1411 ↗(On Diff #60041)

I think moea64_kenter_attr() could call it with M_WAITOK.

1870 ↗(On Diff #60041)

I think this can be M_WAITOK, and the check below removed. It needs tested though.

  • Addressed jhibbits' comments
luporl added inline comments.
sys/powerpc/aim/mmu_oea64.c
1870 ↗(On Diff #60041)

This worked fine in my tests.

This revision is now accepted and ready to land.Jul 24 2019, 2:39 PM
This revision was automatically updated to reflect the committed changes.