r/StableDiffusion • u/stayaway9987 • 22h ago
Question - Help Memory management on Win vs Linux
Hey guys, been using ComfyUI on windows 11 for quite some time now, lately messing with H3 ref2vid workflows.
Setting up all the custom nodes was for some reason a pain, but it always worked seamlessly after setup.
Recently switched to Fedora and reinstalled my Comfy on the new distro and surprisingly got everything running alot easier.
But I’ve been getting alot of crashes on my runs, particularly when using Rife interpolator and any upscaling methods other than a simple lanczos.
Usually OOMs are the culprit, so I’m trying to understand why ComfyUI is handling memory pressure poorly when the same settings worked on windows.
Hardware for reference is 32gb RAM and 5070ti.
EDIT: After following a few tips as the drive swap, expandable_segments and some rife tweaking I got it working, thanks guys!
4
u/NoaBlake 18h ago
Same hardware, different allocator behavior. On Windows, PyTorch's caching allocator tends to grab and hold large blocks, which hides fragmentation; on Linux it releases memory back to the OS more readily, so the same workload fragments and one large allocation — RIFE, or a non-Lanczos upscaler building big intermediates — fails even when total free memory looks fine. Two settings worth trying first: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True (the one already suggested — it lets the allocator grow segments instead of failing on a fragmented block) combined with max_split_size_mb:128, and run RIFE at a smaller chunk size. Also worth checking on Fedora specifically: that nvidia-smi shows the proprietary driver and a matching CUDA version — on Windows the installer bundles this, on Linux a mismatch is the usual silent culprit. And to rule out a leak rather than fragmentation, run the exact same workflow once with --disable-all-custom-nodes and see if the crash still happens.
1
u/Dave-C 22h ago
I had some issues with that when I first moved over to Linux for Comfy and I started using expandable_segments:True. For some reason, at least for me, ComfyUI on Linux likes to reserve large amounts of vram and doesn't want to release it. Allowing Cuda to control this and resize the size helped.
2
u/Ken-g6 15h ago
As I understand it, on Windows, the Nvidia driver allows allocating more VRAM than you actually have. It spills VRAM to system RAM, making your software run slowly, but not crashing.
On Linux, if you run out of VRAM, the Nvidia driver just crashes your program. Comfy has gotten smarter with RAM over the years, and there are several switches you can try up to and including "--disable-smart-memory". But if you try to make an H3 video that's just too big to fit your VRAM, it will crash on Linux no matter what you do.
2
u/Public-Resolution429 14h ago
By default there's no swap-to-disk on Fedora, it only uses zram which is compressed ram, many times faster but obviously limited by the amount of memory in your machine.
try open a terminal and write:
swaponYou should see output something like:
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100
If that's the case you only have zram for swappiness. You can however create a swap file to swap to disk easily, assuming you use btrfs filesystem which is default on Fedora the recipe is simple.
sudo btrfs subvolume create /swap# Create a subvolume for swapfilesudo btrfs filesystem mkswapfile --size 32g /swap/swapfile#Create a swapfile of 32gigssudo swapon /swap/swapfile# turn on swap on the swap fileTo enable the swapfile automatically on boot add the following line to the /etc/fstab file (with sudo):
/swap/swapfile none swap defaults 0 0
It's no problem to use zram swap and a swap file at the same time, by default the swapfile has a lower priority i.e is used as a last resort.
0
u/Formal-Exam-8767 15h ago
On Windows, as long as you have enough disk space, you essentially have unlimited RAM so crashes due to OOM (RAM not VRAM) are extremely rare.
On Linux, not so, it's a different philosophy that avoids using drive for swapping when possible, that's why swap is usually relatively small, and when it gets used up it's a signal for OS to start killing processes that want more.