I ever also found this problem: global ballast doesn't work. So I always use local ballast instead now.
On Sunday, November 6, 2022 at 8:37:55 PM UTC+8 hit.zh...@gmail.com wrote: > Before, I think the memory is allocated by mmap anon, which Linux OS > guarantees reading will return zero value and no physical pages allocated. > When writing happens, the physical pages will be allocated. Then I think > the create a byte slice maybe the same. > > Your idea is clear. I agree with it. > > Just now, I use gdb to dump the ballast anon memory and use hexdump to > check its dirty content, all data is zero (Maybe zeroing happens). > But after turning GC off, it works as expected (no RSS is taken, no > DIRTY). > I think there must be something I didn't get it. > > On Sunday, November 6, 2022 at 8:11:51 PM UTC+8 Jan Mercl wrote: > >> On Sun, Nov 6, 2022 at 12:54 PM Kn (Kn) <hit.zh...@gmail.com> wrote: >> >> > Now the problem begins. I expect the ballast like `ballast := >> make([]byte, 1<<30)` shouldn't take up any physical memory because there's >> no any writing to it. >> >> The backing array is specified to be zeroed, so we cannot say there's >> no writing to it. Depending on the size of the backing array and the >> operating system it may not get written as an optimization if backed >> by memory the OS can guarantee to be zero filled. Only then it may >> remain not yet bound to physical memory. >> >> A simple implementation will just zero it, meaning the opposite >> happens - every byte of the backing array gets written and backing >> pages for it get allocated. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/68ef4bf7-3463-4e14-9e02-657636b66bd7n%40googlegroups.com.
