Win32 FILE_FLAG_SEQUENTIAL_SCAN has a feature/side effect of discarding data from OS cache after first access

Presumably this is for @rattus128's attention, correct me if I am wrong.

On windows 32, aimdo's management of safetensors files opens the handle with FILE_FLAG_SEQUENTIAL_SCAN, presumably for performance reasons.

However, a side effect, or feature, depending upon your perspective is that, with this flag, the OS CACHE only caches the data pulled from the file until it is read once, and then it discards the cached data immediately.

In comfyui, I had hoped that --high-ram would have an impact here, but it doesn't seem to change the file handle creation logistics, and that's why I continue to see massive data reads if the models iterated through a single workflow generation use more VRAM than I have (24GB), even though I have 512GB RAM.

Would it be possible to expose controls on whether this flag is used or not, potentially also, whether FILE_FLAG_OVERLAPPED should also be controlled, as it too may have an impact on windows internal OS caching strategies (I haven't looked deep into this yet, but also, I am concerned about out of order IO making it down to physical devices...which may or may not be related)

Presumably these two flags, among others, were used for fastest initial load, perhaps trying to bypass some of the horrible performance issues seen in the past with out of order faulting causing disk thrash, but ... certainly there's a way to ensure that that is dealt with while also not throwing away OS-cached data on systems built specifically to take advantage of them?

Originally, I was investigating FILE_SHARED_WRITE (unsure why this is used) but ran into the above, which appears to be the real root cause of performance issues on my system,

In the end what I would think would be preferable is both allowing the USER with lots of RAM to cache as much safetensors file data as possible at the OS level, while also ensuring that data access patterns to the mapped memory are both large in size and in linear order, so that faults to slower storage don't suddenly incur massive time and hardware thrashing penalties.

Thanks.
B

Start by locating the Windows safetensors handle creation and how --high-ram affects it, then inspect the use of FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_OVERLAPPED, and FILE_SHARED_WRITE. Done means the relevant flag choices are controllable as requested and the behavior is covered by an appropriate verification of Windows file caching and access patterns.

Written by the indexing model from the issue text.