You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test: ffi_tests::test_memory_functions fails deterministically on CUDA (wired limit is Metal-only) #741
src/lib/mlxcel-core/src/ffi_tests.rstest_memory_functions asserts set_wired_limit(1 GiB) and then get_wired_limit() > 0. The wired-memory limit is an Apple Silicon / Metal concept; on the CUDA backend (GB10) get_wired_limit() returns 0, so the assert at ffi_tests.rs:1756 fails deterministically:
cargo test --release -p mlxcel-core --features cuda --lib test_memory_functions -- --test-threads=1
fails in isolation (0.31 s, assertion failed: limit > 0).
Discovered on 2026-07-11 while running the mlxcel-core ffi regression suite for PR #740 (92/93 passed, this was the only failure). The test predates the #725 work (introduced in commit 0718bce, "Separate mlxcel-core FFI wrappers") and is unrelated to the quantized-matmul changes. It appears the mlxcel-core lib test suite is not part of the root-package CI/test runs on CUDA, which is why it went unnoticed.
What's needed
Gate the wired-limit assertions to the Metal backend (e.g. cfg(feature = "metal") or a runtime backend check), or make the CUDA expectation explicit (assert the call is a no-op returning 0 on CUDA).
Consider whether the mlxcel-core lib tests should run in CI for the cuda feature so backend-conditional tests get exercised.
Acceptance Criteria
test_memory_functions passes on both Metal and CUDA hosts
The backend-conditional expectation is documented in the test comment
A note on whether mlxcel-core lib tests are included in the CUDA test entry point
Activity
test: make the wired-limit expectation backend-conditional (#743)