> On Aug 7, 2020, at 20:30, Linas Vepstas <[email protected]> wrote: > We may even use sparse memory-mapped files representing much much bigger > virtual address space than physical RAM as well as SSD storage. All nodes > have the same file as previously described. Memory management functionality > will deallocate unused blocks to maintain the file sparse enough, keeping > actual storage usage limited. I hope this could simplify handling of Atom's > identity. > > Have you ever done anything like this before? Because some of what you wrote > does not seem right; the kernel does page-faulting and page flush as needed. > There's no "deallocation", there is only unmapping. Mem usage may be > fragmented, but it's never going to be sparse, unless the mem allocator is > broken.
I did but not on this scale. I should be more precise, by "Memory management functionality" I mean "Memory management library code running in Opencog process". By deallocation of unused blocks I'm referring to the hole punching. Here is the demo: https://gist.github.com/crackleware/e01519f4ec16fcba42f5c2bb6151185f <https://gist.github.com/crackleware/e01519f4ec16fcba42f5c2bb6151185f> I'll make better demo with much bigger memory usage to trigger and test the paging, so we know our assumptions are correct. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/45BD1694-273B-4687-80C7-5D0FA90833DF%40crackleware.nu.
