Design feedback: external phys_footprint supervisor boundary

[IonDen]

Hi @jundot — I’m evaluating the architecture gate for a possible Apache-2.0 macOS tool tentatively called mlx-guard. I’m asking before creating any production scaffold because oMLX already has a sophisticated embedded ProcessMemoryEnforcer.

The proposed boundary is external and workload-neutral: run an arbitrary command, sample the full process group’s OS-accounted phys_footprint, preserve typed observation failures, and apply warning/termination policy outside the MLX server or training process.

Bounded evidence on an M1 Max / macOS 26.6.1 so far:

• a 32 MiB root stayed below a 48 MiB ceiling while root + 32 MiB child reached about 68.9 MB;
• anonymous/shared allocations tracked within 0.1% of 64 MiB;
• a 64 MiB Metal buffer added about 69.4 MB and remained charged for at least 10 seconds after the object was released;
• proc_pid_rusage sampling cost was generally tens of microseconds or less.

I inspected oMLX at d5592aa0b6046352a9e226e30ef68c23e9771c53. My current understanding is that oMLX’s enforcer can evict models and control admission inside its server, while get_phys_footprint() returns numeric zero on unsupported/call-failure paths for use with max(active, footprint). The proposed external contract would keep denied, vanished, stale-identity, unsupported, and unavailable outcomes distinct and would supervise non-oMLX commands as well.

Could you give a maintainer’s view on three questions?

1. Is this external arbitrary-command boundary useful alongside oMLX, behavior better contributed to oMLX, or unnecessary overlap?
2. Which failure semantics, process-tree cases, or macOS/Metal constraints would make you reject the design?
3. Do you consider oMLX affected by the footprint/Metal-pressure problem described here, and may I cite your response in the project’s GO/MODIFY/NO-GO architecture record?

This is a design-feedback request, not a feature request for oMLX. I’m happy to clarify the bounded fixture or share the small probe sources.