Joshua Warren’s one-bit kernel fix pushes M1 Max GPU bandwidth on Linux past macOS
A missing power request kept the M1 Max’s memory at its idle floor whenever the GPU worked under Linux. The fix is still an open pull request, off by default and limited to one chip, but the benchmarks are hard to ignore.
Image: omacom/linux-aurora PR #334 (GitHub)
“Linux now beats macOS on Apple silicon GPU memory bandwidth.” That’s how Joshua Warren, who describes himself as part of the Omarchy M team, announced his latest kernel work on X on November 3, 2026. His numbers for an M1 Max running Omarchy: 241 GB/s on Linux before, 361 GB/s on macOS, and 368 GB/s on Linux now. His explanation fits in one line: “The kernel never told the power controller the GPU was busy. One bit fixed it.” The post had passed 170,000 views when we checked.
The details are in pull request #334 on omacom/linux-aurora, which Joshua opened the same day against the integration/aurora branch. According to the PR, bit 9 of the PMP report’s PS-REQ word is the power request for AGX, the GPU, on the M1 Max (t6001). The kernel never set it, so the PMP ignored the GPU’s bandwidth demand and kept memory at its idle floor. The PR says this is the same mechanism already used on t6030, applied to the t600x report layout.
The comparison with macOS is Joshua’s own measurement. According to the PR, a test module that sets the bit by hand moved a GPU read microbenchmark on a 16-inch M1 Max from 241 to 368 GB/s, and the same microbenchmark reads 361 GB/s on macOS. Compute was never the issue: a dependent FMA kernel runs at 4.22 TFLOPS on Linux and 4.28 on macOS. “The shader clock is not what differs. The gap is memory,” the PR reads.
Writes improve too, though they don’t quite catch macOS. On the same machine, the PR reports a write bandwidth microbenchmark at 193.1 GB/s with the fix off and 343.2 GB/s with it on, against 384.9 GB/s on macOS. That leaves a 12 percent gap, “not a factor of two.”
The bigger story for anyone running local models is decode speed. With the patch in its lab-kernel form, on the 7.1.12 tree the branch was first written against, Joshua measured a 2B 4-bit model going from 93.88 to 117.54 tok/s (+25.2%) at 512 tokens of context, and a 9B 4-bit model gaining between 26.7% and 29.4% depending on context length. The PR is upfront that a full image link on this exact tree is “Not covered” yet: the branch compiles on integration/aurora, but the full kernel image was linked from the lab-kernel version of the code.
In practice, the GPU driver now tells the power controller when work is in flight. The bit is set when the first GPU operation starts and cleared 250 ms after the last one ends, so a decode loop submitting every 10 ms keeps a single request open. The bit is also cleared right away when the GPU unbinds.
Before you get excited about your own MacBook, there are real limits. The feature is off by default and needs pmp_report.agx_vote=1 to turn on. It targets apple,t6001 only, and the PR says t6000 is untested. The pull request is still open and unmerged, so it isn’t in any Omarchy release yet: the “Linux now” figure comes from Joshua’s own test machine.
DHH quote-posted the announcement a few hours later: “I knew we could unlock much better performance from the vintage macs by running Omarchy on them, but I didn’t realize it was possible with the M chip generation too! So cool.”
