Files
NX2navi/runtime
chrg6 168a80f2ed Run the copy sweep at normal priority, so a preempted sweep cannot hold the recording and submitting threads.
The review of the NX2NAVI_COPY_RETIRE count found a priority inversion. The "nvn copy sweep" thread ran at the lowest
priority while it held locks the drawing threads take: copy_lock shared for 64 lookups at a time (retire_pass), which
copy_add, release_copies and the submission take exclusive, and later shared takers such as copy_touch queue behind
such a waiter; retire_lock for the queue swap, which retire_queue takes on the recording thread; memory.c's lock through
mem_read_hold and lz_lock through mem_lazy_touches (ctl_fingerprint), which the replay's per-draw check takes. A sweep
preempted inside one of those holds by any thread above the lowest level (the pipeline workers at BELOW_NORMAL are
enough) kept the recording and submitting threads waiting until the scheduler's starvation boost ran it again, which
can take seconds: a new wait on the drawing threads, in the mode the play-test turns on to measure the copies.

retire_main now sets normal priority, the level of the threads it shares the locks with, and keeps it: nearly every step
of a pass holds one of those locks, and a pass is at most 4096 lookups and 16-byte reads every 5 seconds. The block
comment says why. At the default copy_retire = 0 the thread never starts, so nothing changes for players.

tests/copy_sweep_check.py also fails when retire_main lowers the thread below normal priority; against the previous
nvn_api_cmd.c it fails with that message. The check passes, and the compile check of nvn_api_cmd.c (also with -Wall
-Wextra) adds no warnings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-13 18:41:46 -05:00
..
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00