Hit send too soon... On Mon, Aug 10, 2020 at 11:34 PM Linas Vepstas <[email protected]> wrote:
> > > On Fri, Aug 7, 2020 at 3:03 PM Predrag Radovic <[email protected]> > wrote: > >> >> >> By deallocation of unused blocks I'm referring to the hole punching. >> Here is the demo: >> 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. >> > > The next obvious test is to allocate 256MB chunks, fill them with a test > pattern, and keep doing that till RAM runs out. Will the oldest untouched > blocks be automatically flushed to disk? Will the system start thrashing > instead? Will there be some error because maybe mmap won't automatically > shrink RAM usage? > > You might want to do this in a container, so that you don't accidentally > render your desktop inoperable :-) Or do the test on some old victim > machine that you can trash and reboot. > > Might want to run iostat and vmstat while you do this... > so, don't write 10TB, just write a file that is maybe 10x larger than total RAM on the victim. write the test pattern, all the way to the end, then loop back to the beginning and read the test pattern to make sure it's not corrupted. Then write a new pattern, .. repeat in loop until system settles down to some steady-state. It should settle down to whatever the max disk-write/read speed is so maybe 200MBytes/sec for older disks; maybe faster for newer. of course spinners behave differently than ssd ... A variant of that would be to map the whole file, then use a random number to touch random blocks. Does it get slower than the sequential sweep? Or faster (should be faster, I think, because I guess 10% of the time, the random block should still be in RAM, ... 10% because if the file is 10x larger than ram, 90% of it will NOT be in RAM...) > --linas > -- Verbogeny is one of the pleasurettes of a creatific thinkerizer. --Peter da Silva -- 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/CAHrUA36%2BdJ1eac7x5Ffy0FsXJwWUgKXiMWbkNZk4cecAf9-aqQ%40mail.gmail.com.
