Testing of an MSI Prestige laptop built on Nvidia’s RTX Spark platform has identified a major native Linux performance problem tied to the machine’s power-management system. The test found that the GPU clock fell to roughly 780 MHz when the laptop was connected to wall power under Linux, compared with more than 2 GHz under Windows.
The practical effect was substantial. Running the GPT-OSS-120B model, Windows produced 65.4 tokens per second and Windows Subsystem for Linux reached 65.1. Nvidia’s DGX Spark desktop produced 61 tokens per second. Native Linux on the laptop managed 13.9 tokens per second. In a separate vLLM test with eight concurrent clients, WSL reached 127 tokens per second while native Linux delivered 39.5.
A longer benchmark reinforced the result: Windows completed the workload in about eight minutes, while Linux required 37 minutes. GPU temperatures remained between 40C and 47C, indicating that heat was not the limiting factor. The unusual behavior also reversed on battery power. When unplugged, Linux performance rose to around 61 to 67 tokens per second and the GPU clock approached 1,800 MHz.
The investigation linked the slowdown to Nvidia Platform Controllers and Framework, a Windows component that manages the shared power budget between the CPU and GPU. Disabling that controller in Windows reproduced the Linux-like slowdown, dropping the clock to about 786 MHz. Re-enabling it restored normal performance. The tester reported that the relevant firmware power table is encrypted and that Linux currently lacks the corresponding logic needed to use it.
Installing Linux was possible but required several workarounds. Debian initially lacked support for Wi-Fi, input devices and the GPU, while an Omarchy installation included Nvidia’s open kernel driver. The machine’s unified memory split also had to be adjusted from Windows so Linux could see most of its 128 GB. Once configured, display, audio, input and CUDA acceleration worked. Early installation also had display-output limitations, illustrating that the performance fault was not the only compatibility issue encountered during setup.
For developers who need Linux-first tools such as vLLM and SGLang, WSL was the more practical route in this test because it inherited the Windows driver stack and maintained GPU boost behavior. Its default memory allocation still needed adjustment for large models. That tradeoff means developers can retain access to a Linux user environment, but the host operating system and Nvidia's Windows power controls remain essential to full speed.
The findings are based on one detailed hardware test, not a broad survey of every RTX Spark laptop, distribution or firmware version. They therefore do not establish that every configuration will behave identically. Even so, the reproduced controller behavior points to a platform-level Linux support gap rather than thermal limits or an ordinary application setting. A durable resolution would require Nvidia to provide Linux with equivalent access to the platform’s power-management capability.
