From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <64399b170909020101n10787c71qf10f9fd5147274e2@mail.gmail.com> References: <64399b170909020101n10787c71qf10f9fd5147274e2@mail.gmail.com> Date: Wed, 2 Sep 2009 10:58:11 +0200 Message-ID: <599f06db0909020158t4f608b1cgec50f1b5120e68c3@mail.gmail.com> From: Gorka Guardiola To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] lowest valid stack address Topicbox-Message-UUID: 5e15a1ee-ead5-11e9-9d60-3106f5b1d025 2009/9/2 Andr=E9s Dom=EDnguez : > 2009/9/2 erik quanstrom : >> >> aside: from the overcommit vm discussion. >> in http://9fans.net/archive/2000/06/634 rob >> says that plan 9 doesn't overcommit vm. >> what's the history here? > > Exactly two years ago you started a thread about > memory overcommit. If I remember correctly, plan9 > overcommits vm. Few weeks later the Go program > from gorka crashed while allocating the stack, maybe > an overcommiting check was added, probably gorka > knows. > I don=B4t think there was an extra check added for this, that was probably coincidence. I think that was some other effect. The vm space may (and normally is) bigger than the physical memory (that is what vm is about). but not the quantity really backed up by physical memory because there is no swap (there is but noone uses it). If you don=B4t 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 (I was doing some funny things with it) of stack using the thread library and I probably ran out of vm space for the proc and the kernel does check this. --=20 - curiosity sKilled the cat