Re: [9fans] lowest valid stack address

[erik quanstrom <quanstro@quanstro.net>]

> > 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