Re:The final step for huge-page swapping
by sterlind on Wednesday July 04, 2018 @01:17AM
(#17455390)
the feature you're looking for is called opening a memory mapped file. I've seen tremendous performance improvements, but it's a really underused feature for some reason. Memory map Performance is incredible.
Re:The final step for huge-page swapping
by bluejekyll on Wednesday July 04, 2018 @10:19AM
(#17457394)
> it's a really underused feature for some reason
My suspicion is that it’s mainly because memory mapping files, while safe for reading, have a whole bunch of edge cases where the file can accidentally be corrupted.
Does Windows have any analog to madvise()? It seems like that's probably necessary to making things work well when you're mapping huge data sets, unless you're sure they reside on really fast storage.
Windows 8 and later has PrefetchVirtualMemory[1]. Before that your best bet is to get a little hacky and try reading the file asynchronously to get it in the cache (Windows caches files pretty aggressively, so this more or less works).
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...
Re:The final step for huge-page swapping
by senozhatsky on Wednesday July 04, 2018 @04:08AM
(#17455901)
Seems that VirtualAlloc() [1] is a little bit closer to madvise(), but still is pretty far. madvise() is quite
powerful. For instance, take a look at MADV_FREE.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
-ss
I figured the use-case here was MADV_WILLNEED, which is what PrefetchVirtualMemory is for. VirtualAlloc flags would be for things like reserving virtual pages without committing them.
There's no single API on Windows that does the myriad of things that madvise does.
Re:The final step for huge-page swapping
by ddorian43 on Wednesday July 04, 2018 @01:29AM
(#17455427)
Yep, see lmdb read performance. Or many search engines doing mmap.
> I don’t know whether the present topic would let you bypass this limitation
I can't imagine that it would, since it's just swapping. That's why I asked the question.
How to take advantage of the nonvolatile aspect of that memory as you describe is a much broader, more complicated topic, involving bootloaders and kernels.
One solution is to stream the mip levels, and to create virtualized mipmaps. This basically lets you create a 128k by 128k texture, which works fine because only small blocks are loaded. It’s literally the same thing as virtual memory, but for texture memory.
One downside is that when you shut down the game / simulation, all of that data no longer exists. It was virtual. It either streamed from the sever or you packed it to disk somewhere. Either way you have to set it up again the next time the program starts.
I don’t know whether the present topic would let you bypass this limitation, but if there was some way to start a program with a huge amount of memory allocations preloaded, that would be very attractive. And if you can reboot without losing that, then suddenly you can start crafting persistent worlds that load instantly with ~infinite resolution.
This is the dream that voxel tech was supposed to make into reality, and it will only become more of a concern over time as mixed reality tech matures.