How can the Metal resource limit be queried or configured on macOS?

[Lyxot]

I encountered the following error while running an MLX workload:

[metal::malloc] Resource limit (499000) exceeded.

The Metal backend reads iogpu.rsrc_limit and uses the hardcoded 499000 fallback when that value is unavailable. On my system, sysctl iogpu.rsrc_limit returns unknown oid, so MLX always reports the fallback value. #3512 (review)

Is there a supported way to query the actual Metal resource-object limit on current macOS versions? Is there also a supported way to configure that limit, either through sysctl or another mechanism?

[XXXXRT666]

I ran a standalone Metal probe on an M4 with 32 GB RAM and macOS 27.0. With direct 1-byte MTLBuffer allocations using the same shared/untracked options as MLX, the amortized cost was 256 bytes per buffer up to exactly 2^19 = 524,288. Starting at buffer 524,289, MTLDevice.currentAllocatedSize increased by 16 KiB per additional buffer.

Direct allocation still succeeded with 1.1 million live buffers, and heap-backed allocation succeeded with 2 million. This suggests that 499,000 is not a hard Metal object limit on this system. I also could not find iogpu.rsrc_limit in the macOS 27 SDK headers or any supported public API for querying or configuring it. Maybe just increasing the limit would be a good idea.

[katlun-lgtm]

One thing you can check from Python: mx.device_info()["resource_limit"] reports the value MLX is actually using. On your machine that'll read back 499000, since iogpu.rsrc_limit comes back as unknown oid and the code falls back to the hardcoded value in device_info.cpp.

For querying the real limit — I don't think there's a supported way. iogpu.rsrc_limit is undocumented and, as you found, isn't in the macOS 27 SDK, so MLX only reads it opportunistically. Your probe backs that up nicely: if an M4 takes 1.1M direct / 2M heap-backed buffers without complaint, 499000 isn't a hard Metal limit on recent systems, it's just a conservative guard.

Configuring it is really two separate knobs:

• The OS-side limit — zcbenz mentioned on metal: scale rsrc_limit fallback with hw.memsize #3512 you can try sudo sysctl iogpu.rsrc_limit=<n>, but that only does anything where the OID exists, which isn't your case.
• MLX's own guard (resource_limit_ in the allocator) — right now there's no way to change it. We expose set_memory_limit, set_cache_limit and set_wired_limit, but resource_limit is the odd one out: it's read once at init and never settable.

That last gap looks like the cleanest fix — add a set_resource_limit mirroring the other three so anyone hitting the conservative fallback can just raise it themselves. It's additive (defaults don't change, so smaller-RAM machines are unaffected) and it sidesteps the default-fallback policy question that came up on #3512. The one caveat is that pushing the guard above the true driver limit would just move the failure into Metal itself, but that's the same trade-off set_memory_limit already makes. Happy to put up a PR if the maintainers are open to it.