> > Exactly two years ago you started a thread about > > memory overcommit. If I remember correctly, plan9 > > overcommits vm. Few weeks later the Go program
i thought this was common knowledge, and so i ommitted recounting the discussion. since it's not common knowledge i'll recount. plan 9 overcommits vm. a large amount of this overcommit is due to the stack, since the kernel gives each process a 16mb segment. overcommit means you can malloc n bytes or even use a few extra bytes on the stack but will fault when accessing it. needless to say, overcommit is not much fun. executables are paged out even with no swap. the reason for the crash of the Go program is that the stack segment is 16mb. while plan 9 will demand load and zero fill within the stack segment, it's just a fault to try to access memory outside of any segment. therefore, we know the Go program had a stack >=16mb. (by careful arrangement, the page below the stack is generally invalid — it's not in any segment.) the bss, stack and shared segments are zero-filled on demand. it doesn't appear they can be paged out. > If you don´t touch the memory, > it never gets mapped in, so you may reserve a big chunk, but it has to fit > in your vm in the space between the stack and the bss. In my go program > I was reserving something unreasonable like 1Gb the maximum segment allowed by the pc kernel is 1984mb. (SEGMAPSIZE*PTEPERTAB*BY2PG), see segment.c:/^by2pg - erik
