pinned-memory-related issue

[NeverOccurs]

Sometime ago I wrote an inquiry into smart memory causing OOM when using video models like wan and, recently, minimax H3 (#14462). After months' experiment, I did many things including expanding virtual RAM on disk, etc. And smart memory and dynamic vram both works fine. Yet the problems persist from time to time. I finally disabled pinned-memory and video-related workflows work smoothly without error since then. I read that pinned-memory is about locking a part in RAM and allow faster RAM-VRAM exchaange. What might be the reason behind this potential bug and what can I do if I really want this acceleration?

[yudin-s]

Pinned memory is not a general "more speed, no downside" switch. For the video workflows you mention, disabling it being more stable is a useful signal.

In ComfyUI's current code, pinned memory is used as a host-side buffer for model/offload transfers. The pin_memory() path allocates host buffer space, asks the memory manager for pin budget/registerable size, releases extra RAM headroom first, and then calls CUDA host registration (cudaHostRegister). If those checks fail, it tries to reuse/steal an existing pin instead of making an unlimited new one. The CLI flag --disable-pinned-memory bypasses that path.

So the likely reason is system-RAM pressure, not only VRAM pressure. Pinned host memory is RAM that the OS/GPU driver cannot freely page/move. On huge video models, you can end up with this pattern:

• VRAM is already tight, so smart/dynamic VRAM offloads more data through system RAM.
• Pinned memory reserves additional non-pageable host memory for faster CPU<->GPU copies.
• The workflow also needs normal pageable RAM for frames, latents, decode/encode buffers, custom nodes, Python objects, and disk cache.
• Once physical RAM gets fragmented or close to full, the pinned path can make the system less forgiving even if a large pagefile exists.

That also explains why expanding virtual RAM did not fully fix it: pagefile helps normal pageable memory, but it does not make pinned host pages cheap. For big Wan / MiniMax-style video runs, stability can be better with pinned memory off because the OS has more freedom to manage RAM.

If you want to test whether the acceleration is worth keeping, I would do it as an A/B test on the same workflow:

1. Start from the stable configuration with pinned memory disabled.
2. Lower one memory dimension first: fewer frames, lower resolution, smaller batch/context, or a smaller model/quant.
3. Re-enable pinned memory only when you have a large amount of free physical RAM before the run, not just pagefile/virtual RAM.
4. Watch system RAM committed/used, GPU dedicated/shared memory, and whether failure happens during model load/offload or during sampling/decoding.
5. If failures return only with pinned memory enabled, keep --disable-pinned-memory for video workflows and treat pinned memory as useful mainly for workloads that fit comfortably in physical RAM.

In short: yes, pinned memory can speed transfers, but on memory-edge video workflows it can make RAM pressure worse. If disabling it makes Wan/MiniMax runs smooth, that is a valid production setting rather than a workaround you must undo.

If this matches your tests, please mark it as answered so other video-workflow OOM cases can find the pinned-memory tradeoff.

[NeverOccurs]

Pinned memory is not a general "more speed, no downside" switch. For the video workflows you mention, disabling it being more stable is a useful signal.

In ComfyUI's current code, pinned memory is used as a host-side buffer for model/offload transfers. The pin_memory() path allocates host buffer space, asks the memory manager for pin budget/registerable size, releases extra RAM headroom first, and then calls CUDA host registration (cudaHostRegister). If those checks fail, it tries to reuse/steal an existing pin instead of making an unlimited new one. The CLI flag --disable-pinned-memory bypasses that path.

So the likely reason is system-RAM pressure, not only VRAM pressure. Pinned host memory is RAM that the OS/GPU driver cannot freely page/move. On huge video models, you can end up with this pattern:

• VRAM is already tight, so smart/dynamic VRAM offloads more data through system RAM.
• Pinned memory reserves additional non-pageable host memory for faster CPU<->GPU copies.
• The workflow also needs normal pageable RAM for frames, latents, decode/encode buffers, custom nodes, Python objects, and disk cache.
• Once physical RAM gets fragmented or close to full, the pinned path can make the system less forgiving even if a large pagefile exists.

That also explains why expanding virtual RAM did not fully fix it: pagefile helps normal pageable memory, but it does not make pinned host pages cheap. For big Wan / MiniMax-style video runs, stability can be better with pinned memory off because the OS has more freedom to manage RAM.

If you want to test whether the acceleration is worth keeping, I would do it as an A/B test on the same workflow:

1. Start from the stable configuration with pinned memory disabled.
2. Lower one memory dimension first: fewer frames, lower resolution, smaller batch/context, or a smaller model/quant.
3. Re-enable pinned memory only when you have a large amount of free physical RAM before the run, not just pagefile/virtual RAM.
4. Watch system RAM committed/used, GPU dedicated/shared memory, and whether failure happens during model load/offload or during sampling/decoding.
5. If failures return only with pinned memory enabled, keep --disable-pinned-memory for video workflows and treat pinned memory as useful mainly for workloads that fit comfortably in physical RAM.

In short: yes, pinned memory can speed transfers, but on memory-edge video workflows it can make RAM pressure worse. If disabling it makes Wan/MiniMax runs smooth, that is a valid production setting rather than a workaround you must undo.

If this matches your tests, please mark it as answered so other video-workflow OOM cases can find the pinned-memory tradeoff.

that helps a lot, thanks!

[NeverOccurs]

Pinned memory is not a general "more speed, no downside" switch. For the video workflows you mention, disabling it being more stable is a useful signal.

In ComfyUI's current code, pinned memory is used as a host-side buffer for model/offload transfers. The pin_memory() path allocates host buffer space, asks the memory manager for pin budget/registerable size, releases extra RAM headroom first, and then calls CUDA host registration (cudaHostRegister). If those checks fail, it tries to reuse/steal an existing pin instead of making an unlimited new one. The CLI flag --disable-pinned-memory bypasses that path.

So the likely reason is system-RAM pressure, not only VRAM pressure. Pinned host memory is RAM that the OS/GPU driver cannot freely page/move. On huge video models, you can end up with this pattern:

• VRAM is already tight, so smart/dynamic VRAM offloads more data through system RAM.
• Pinned memory reserves additional non-pageable host memory for faster CPU<->GPU copies.
• The workflow also needs normal pageable RAM for frames, latents, decode/encode buffers, custom nodes, Python objects, and disk cache.
• Once physical RAM gets fragmented or close to full, the pinned path can make the system less forgiving even if a large pagefile exists.

That also explains why expanding virtual RAM did not fully fix it: pagefile helps normal pageable memory, but it does not make pinned host pages cheap. For big Wan / MiniMax-style video runs, stability can be better with pinned memory off because the OS has more freedom to manage RAM.

If you want to test whether the acceleration is worth keeping, I would do it as an A/B test on the same workflow:

1. Start from the stable configuration with pinned memory disabled.
2. Lower one memory dimension first: fewer frames, lower resolution, smaller batch/context, or a smaller model/quant.
3. Re-enable pinned memory only when you have a large amount of free physical RAM before the run, not just pagefile/virtual RAM.
4. Watch system RAM committed/used, GPU dedicated/shared memory, and whether failure happens during model load/offload or during sampling/decoding.
5. If failures return only with pinned memory enabled, keep --disable-pinned-memory for video workflows and treat pinned memory as useful mainly for workloads that fit comfortably in physical RAM.

In short: yes, pinned memory can speed transfers, but on memory-edge video workflows it can make RAM pressure worse. If disabling it makes Wan/MiniMax runs smooth, that is a valid production setting rather than a workaround you must undo.

If this matches your tests, please mark it as answered so other video-workflow OOM cases can find the pinned-memory tradeoff.

btw, sometimes I up the resolution it does not crash. I can see there are additional spare VRAM ~1-2GB. but sometimes when I lower the resolution, VRAM is totally full and inference becomes incredibly slow. Do you know why?

[yudin-s]

Yes. The confusing part is that "lower resolution" only lowers one part of the memory budget: activations/latents for that specific run. It does not guarantee that the same models, cache state, attention path, previews, VAE/decode buffers, or offload decisions are active.

In ComfyUI, the memory manager tries to keep/reuse loaded models, calculates required memory before each model load, unloads only when needed, and can partially load/offload models when the free-memory estimate is too tight. So two runs that differ only in resolution can still land in different states:

• higher resolution may force ComfyUI to unload something earlier, leaving 1-2 GB visibly free during sampling;
• lower resolution may make the estimate look safe, so more model weights/cache stay resident, and the monitor shows VRAM nearly full;
• if the next node then needs a little more memory, it can cross the pressure threshold and start offloading/using shared memory/CPU RAM, which is when inference becomes extremely slow.

Also, Task Manager / GPU monitors can be misleading here. "VRAM full" can include allocator cache/reserved memory, which is not always bad. The bad case is when speed drops at the same time, because that usually means real memory pressure: model parts are being moved, tensors are falling into shared GPU memory, or ComfyUI/PyTorch is repeatedly freeing/reallocating.

I would compare it this way:

1. Restart ComfyUI so both tests start from the same cache/model state.
2. Run the same workflow once at the lower resolution and once at the higher resolution.
3. Watch the ComfyUI console for model load/offload messages and the Windows GPU view for dedicated VRAM vs shared GPU memory.
4. If the slow run uses shared GPU memory or logs more model loading/offloading, it is not really "lower resolution is heavier"; it is a different memory-management state.

For a practical fix, keep --disable-pinned-memory if that is the stable baseline, then try reserving a bit more headroom instead of letting the run sit exactly on the edge, for example --reserve-vram 1.5 or --vram-headroom 1 depending on which option your launch setup uses. That may look like "wasting" 1 GB, but it can be faster if it prevents offload thrashing.

So the short version is: resolution changes activation memory, but the slowdown is probably from crossing a model/cache/offload threshold, not from lower resolution inherently needing more VRAM.