Unloading a module is busy work, sceKernelVolatileMemTryLock is quick

From pspautotests threads/scheduling/syscallkinds:

- sceKernelUnloadModule takes ~400us that better threads can preempt
  and worse ones don't get in on, so it uses the busy delay rather than
  a wait.
- A successful sceKernelVolatileMemTryLock takes under 100us. It ate
  500000 cycles as a hack for Crash Tag Team Racing, which has since
  moved to (and no longer needs) the DrawSyncEatCycles compat flag.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This commit is contained in:
Henrik RydgårdandClaude Opus 5.5 committed 2026-09-29 09:56:28 -06:00
1 parent 8301c35d7d
commit c1e70c9686
2 files changed
+6 -6

No files matched your search

+3 -1
View File
@@ -2714,7 +2714,9 @@ static u32 sceKernelUnloadModule(u32 moduleId) {
module->Cleanup();
kernelObjects.Destroy<PSPModule>(moduleId);
return hleDelayResult(hleLogDebug(Log::sceModule, moduleId), "module unloaded", 500);
// About 400us of work that better threads can preempt, and worse ones don't get in on
// (tests/threads/scheduling/syscallkinds).
return __KernelBusyDelayResult(hleLogDebug(Log::sceModule, moduleId), (int)usToCycles(400), "module unloaded");
}
u32 __KernelStopUnloadSelfModuleWithOrWithoutStatus(u32 exitCode, u32 argSize, u32 argp, u32 statusAddr, u32 optionAddr, bool WithStatus) {