From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
Subject: Re: Please test: parallel fault handling
To: tech@openbsd.org
Cc: naddy@openbsd.org, robert@openbsd.org, sthen@openbsd.org
Date: Tue, 13 May 2025 13:57:33 +0200

On Wed, Apr 30, 2025 at 11:39:15AM +0200, Martin Pieuchot wrote:
> Hello,
> 
> Diff below enables running the fault handler in parallel.  Please test
> an report back, with dmesg, if this increases or decreases the perfs of
> your usual setup.

I see a performance improvement in basic testing on an amd64 AMD 8
cores VM, a Mac Mini M2 pro with 10 cores, a sparc64 LDOM with 16
cores and a riscv64 Hifive Unmatched with 4 cores.  On the amd64 and
arm64 machines I have completed a ports bulk build.  Bulk build started
but unfinished so far on the riscv64 and sparc64 machines - don't hold
your breath.

The sparc64 LDOM went into two panics - I somehow managed to break it
out of ddb after the first panic due to bogus conserver.  The data
below is minimal, sorry, I didn't recover the full trace from dmesg
after the 1st panic, and 'mach ddbcpu 0' locked up during the 2nd
panic.

I had not run a sparc64 bulk build on this machine in the recent
months, and I don't know whether both panics are related to your diff,
but I'll do my best to try and reproduce them.  Currently I've
restarted the bulk build without the uvm change. Maybe someone with
more sparc64 knowledge will bring some clue here.


First panic:
  pmap_page_protect: gotten pseg empty!
  Stopped at      pmap_page_protect+0x594:        nop

Second panic:
  ddb{11}> sh panic
  *cpu11: trap type 0x34 (mem address not aligned): pc=1012f68 npc=1012f6c pstate=820006<PRIV,IE>
  ddb{11}> tr
  trap(400fe6b55f0, 34, 1012f68, 820006, 18ec11, 1cd1d60) at trap+0x334
  Lslowtrap_reenter(4010253a040, 995f566000, deafbeaddeafc10d, 260, 3, 30) at Lslowtrap_reenter+0xf8
  pmap_page_protect(4001016fa38, 0, 400fe6b5808, 4000d89f2d0, f85dd, 0) at pmap_page_protect+0x2dc
  uvm_pagedeactivate(4001016f9d0, 19ce130, 17c6578, 40015a505a4, 1, 1) at uvm_pagedeactivate+0x54
  uvn_flush(40103f05400, 0, 1118e000, 14, 1, 0) at uvn_flush+0x448
  uvn_detach(40103f05400, 4010c97b080, 4, 0, 0, 1000000) at uvn_detach+0x158
  uvm_unmap_detach(400fe6b5c68, 0, 9be, 0, 40015a505a4, 17d3558) at uvm_unmap_detach+0x68
  uvm_map_teardown(4010472d730, 4000, 1889628, 40107720000, 587, 17d4280) at uvm_map_teardown+0x184
  uvmspace_free(1c7d000, 4010472d730, 4, 17d4280, 0, 6) at uvmspace_free+0x64
  reaper(40015a505a0, 40015a505a0, ce, 100, f02662b0, 4000) at reaper+0xf8
  proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x10

My 2 cents,
-- 
jca