Thanks for the clarification Nate. My very simple high-level question is still: is the patch safe? The big benefit is that simulating a system with a large physical memory is not killing the host.
>From your argument I guess the answer is: most likely, but not based on always guaranteeing zero, but rather that zeroing should not be necessary. Concerning the zeroing I would think the only case when we would re-use potentially deallocated memory would be checkpoint/switching. Agreed? The other question I have is, if we do not worry about the zeroing, then why use mmap and not malloc? Thoughts? Andreas On 26/04/2013 22:48, "nathan binkert" <[email protected]> wrote: >> Any modern OS should zero allocated pages for security reasons alone. >>Just >> to avoid leaking info across processes. Of course the OS could do this >> zeroing when reclaiming pages, but I'd assume most would do it lazily >>and >> just zero when they needed to re-allocate. > >tl;dr If memory is allocated by mmap with MAP_ANONYMOUS, it will be >zeroed this has pretty much always been the case. > >Heh. You don't even need to add the qualifier modern. This has >basically just always been done. Most OSes now have a single "zero >page" which is indeed a page full of zeroes. All new virtual memory >(i.e. created with mmap w/ MAP_ANONYMOUS which incidentally grew out >of mapping /dev/zero) is mapped to the zero page, but that page is >marked read-only. When an application actually does a write, then, at >that time, a fault occurs and a real zero page is allocated and >provided. As to when pages are actually zeroed, when memory is >returned to the OS, zeroing happens in a background thread and is only >done on demand when there are no zeroed pages available. > >Now, all that said, this only applies to *new* virtual memory. If >memory is allocated with malloc, it may have been recycled memory >(from a previous free()) and there are no guarantees about whether or >not the memory is zeroed. > >This particular patch seems to have to do with physical memory, and >the for zeroed physical memory is system dependent. When a machine is >booted, memory is of course random. In some systems the bios/console >code zeroes memory before the OS starts and the OS may expect this >behavior. On some systems, this does not happen since the OS knows it >needs to zero the memory anyway. There were also projects like RIO >(Peter Chen) that explicitly required physical memory to not be zeroed >so the OS could be rebooted during a failure, but dirty cache data >could be rescued. Kernels like linux probably take a least common >denominator approach and assume nothing about zeroing, but embedded >systems would potentially be different. > > Nate >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
