Global Memory Trim Status

If you're here, you probably installed ComfyUI-Global-Memory-Trim because your WSL2 ComfyUI keeps losing its mind after hours of generation - stalling mid-batch, RSS creeping toward swap, the whole "it worked fine this morning" routine. The pack's global patch (gc + glibc malloc_trim(0) around every node execution) is meant to fix exactly that. GlobalMemoryTrimStatus is the simplest node in the pack: it takes no inputs, wires into nothing, and answers one question - is the trim actually running, and what did it last do?

What it is

It's a diagnostic readout, not a control. Unlike its sibling GlobalMemoryTrimNow, this node never triggers a trim. It snapshots two things at the moment you run it: the config the patch loaded from its environment variables, and the last trim result the patch recorded. If you've been eyeballing a workflow that stalls and want to know whether the heap trim fired, what RSS looked like going in and coming out, and whether the interval or RSS-threshold guards are skipping trims, this is your one-stop answer.

Because it's a pure status node, it's also the fastest way to confirm the patch actually installed. The pack monkey-patches ComfyUI's execution.get_output_data at import time, which means it should be active even with an empty canvas - but "should be" isn't "is". This node tells you for sure.

What you actually get

One output, status (STRING): a JSON-style dict with two keys.

• config - a config_summary() dump: enabled, patched, trim_before, trim_after, gc_collect, interval, min_rss_mb, log, plus linux_like, wsl, and current rss_mb / mem_available_mb. That patched field is the money one: true means the global hook is live; false means something stopped it (like COMFYUI_GLOBAL_TRIM=0).
• last_trim - the last result from trim_native_heap(): which phase ran (before, after, or manual), rss_before_mb, rss_after_mb, delta_mb, malloc_trim_rc, and a reason that explains skipped trims ("interval skip", "rss below threshold", "non-linux no-op").

It's a snapshot, not a live monitor - re-run the node to refresh it, or leave it in your graph and double-click it whenever the workflow feels off. If you want the trims themselves as visible steps instead, use GlobalMemoryTrimNow; if you just want the vitals, this is the node.

Installing

Same story as the whole pack - clone it in, restart, done. No dependencies beyond Python's standard library, no model downloads:

cd ~/ComfyUI/custom_nodes
git clone https://github.com/xmarre/ComfyUI-Global-Memory-Trim

Or find "Global Memory Trim" in ComfyUI Manager. When ComfyUI starts, the console should show Installed global memory trim patch: enabled=True before=True after=True .... The COMFYUI_GLOBAL_TRIM_* env vars that shape behavior (_BEFORE, _AFTER, _INTERVAL, _MIN_RSS_MB, _GC, _LOG) are all reflected in the config this node reports - so it doubles as your way to verify you actually set them the way you thought you did.

Common issues

• patched: false - the patch didn't install. Usually COMFYUI_GLOBAL_TRIM=0 is set in the environment, or the execution module changed in a newer ComfyUI and the monkey-patch bailed defensively (the pack is written to fail non-fatally). Check the startup log line.
• "non-linux no-op" - you're on Windows/macOS. malloc_trim is a glibc thing; the patch simply does nothing outside Linux/WSL, and this node exists to tell you that plainly.
• delta_mb near 0 on every run - not necessarily a problem. If the heap has nothing to release, malloc_trim(0) is cheap and returns nothing. If you expected a big drop and keep seeing zero, check whether the RSS threshold or interval guard is silently skipping - the reason field will say so.
• Remember the scope: this is a CPU/native-heap tool. It will never show VRAM freed or models unloaded, because it doesn't do those things. If your diagnosis is GPU memory, you're reading the wrong gauge.