Previous result no longer cached, since PR 15027 (fast-disk doesn't resolve) Also, will old less-aggressive-pinning return as a feature?

[808charlie]

Since PR 15027, cache of previous generations seems non-existent.

I was really happy with v28, as linux managed caching perfectly in the 112GB system RAM I allocate (GPU=5090).

I tried --fast-disk, but whilst it stops pinning, it doesn't bring back the caching of generation. That's the one thing I wanted Comfy to pin some space for.

@rattus128 , you wrote "We can make the old way a separate option but its probably best to just consolidate with this and --fast-disk" in the pull.
Is there a chance the old option will return?

Perhaps there's a setting that can achieve this I overlooked?

I can't say I've seen any massive slow-ups since the pinning, and your work with pinning has been a huge benefit in allowing one to smoothly use models beyond one's VRAM - thank you. 15027 seems somewhat without benefit on my spec as yet.
If I flicked between an int8-convrot, a BF16, and finetune in a workflow - linux would cache them all just fine without need for Comfy to take responsibility.

Steps to reproduce

1. Generate an image in Krea with one sampler (run)
2. Switch to another sampler (run)
3. Switch back (run).

Run 3 used to generate from cache. Same for changing seeds. Now it doesn't.

[ozhasta]

i agree with @808charlie. i will be glad if old ram management returns (maybe as an option) like until 29.0, it was perfect. i have 7.5gbps NVME very fast disk.
but --fast-disk is not solving my issues.

[NeedsMoar]

Dear lawd is that mess still in place? SD1.5 models that used to be insta-load for me have been jumping back and forth between 24GB of vram and 24GB of "shared" and next-to-no vram used for about 60 seconds before doing anything every time I change a parameter... I mean It's supposedly helping somebody but does anyone have the old revision number I can pull to get back to not having some weird hack that overrides Windows' vram management and ignores driver CUDA settings (sometimes, since it doesn't hook all the calls the C++ in Torch uses, just the ones that python diverts)? Why is this thing not an optional setting? Detours-hooking drivers isn't exactly a good idea in the first place anyway and it's process-specific. It used to just be slowing down comfy and now it's making the entire windowing system stutter.