Looking at the patch, particularly the changes to physical.cc, it looks like we're only talking about zeroing memory immediately after we mmap it with MAP_ANON, so based on that I would say that the explicit zeroing is clearly redundant and it should be safe to remove it.
If we ever replaced the mmap MAP_ANON with another allocation method, then it might become an issue. Steve On Fri, Apr 26, 2013 at 3:20 PM, Andreas Hansson <[email protected]>wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
