[Engine] Windows, RTX 5090 D: engine started from a low-priority process inherits Low I/O priority although CPU class is Normal: PLE reads ~15x slower, decode -14% #4733

Summary

I found that the engine's speed depends on the I/O priority it inherits from the process that launches it. With the CPU priority class forced to Normal, a child of a low-priority launcher still gets I/O priority 1 (Low) (normal: 2). On my machine this made the same engine with the same arguments run decode about 14% slower and cold prompt reads 3-5x slower, with the PLE direct-read probe reporting the drive as slow. Setting the I/O priority back to normal in the launcher removed the whole difference. The memory page priority, which is also inherited low, made no difference.

Environment

Windows 11, RTX 5090 D (32 GB), Ryzen 7 9800X3D, 96 GB DDR5, NVMe, NVFP4 GPTQ pack, engine 0.1.54 (control 0.1.53 server layer), 256K context, same 40 arguments in every run, same boot.

What I measured

The launcher was an AI coding agent's terminal (Below-Normal CPU, I/O 1, page 2). Values read with NtQueryInformationProcess (class 33 = ProcessIoPriority, 39 = ProcessPagePriority). The engine started from that launcher inherits I/O 1 and page 2 even though its CPU class is forced to Normal; the engine started by the desktop app has I/O 2 and page 5.

I then changed the two inherited values one at a time in the launcher process before CreateProcess (NtSetInformationProcess). Same engine, same arguments, same disk, each row a fresh load:

The same engine started by the desktop app (I/O 2, page 5) gives the same numbers as the last two rows. The order of runs was launcher (slow) -> desktop app (fast) -> launcher (slow) -> launcher with the fix (fast), so it is not drift in machine state. A reboot, Windows fast startup off, power plan, fan curve, memory and BIOS settings were checked first and made no difference.

Fix that worked (launcher side)

Before CreateProcess, set the launcher process's own I/O priority back to normal; the child inherits it:

import ctypes
nt = ctypes.windll.ntdll; k = ctypes.windll.kernel32
k.GetCurrentProcess.restype = ctypes.c_void_p
h = ctypes.c_void_p(k.GetCurrentProcess())
v = ctypes.c_ulong(2)                      # ProcessIoPriority = 2 (Normal)
nt.NtSetInformationProcess(h, 33, ctypes.byref(v), 4)

Impact

Any launcher that runs at low priority passes this on: Task Scheduler tasks with the default priority, services, and terminals or scripts started from IDEs or coding agents. Because the engine's own check only looks at the PLE read rate, the symptom shows up as "the drive is slow" (--ple-io direct measures slow here), although the drive is fine. The CPU priority class is the setting people usually check, and it can be Normal while the I/O priority is low.

Suggestion

At start, have the engine (or serve.server) set its own I/O priority to normal, or warn when it reads a low value.

Possibly related

#126 and #3897 describe slow loading when started from Task Scheduler / a Below-Normal host, and #1425 describes slow PLE direct reads on a fast SSD. I have not verified that the cause is the same there; I only mention them in case the inherited I/O priority is worth checking.