From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <462e5c2c6d902e4a2f54b6f41c2e4101@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 overcommits memory?
Date: Mon,  3 Sep 2007 16:48:59 -0400
From: geoff@plan9.bell-labs.com
In-Reply-To: <2c68bbb34242a932e4b3e9be554c6f18@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: b67f4b1c-ead2-11e9-9d60-3106f5b1d025

venti/copy is just an example; programs may legitimately have large
stacks.

If your machines are regularly running out of VM, something is wrong
in your environment.  I would argue that we'd be better off fixing
upas/fs to be less greedy with memory than contorting the system to
try to avoid overcommitting memory.  If one did change the system to
enforce a limit of 16MB for the aggregate of all system stacks, what
would happen when a process needed to grow its stack and the 16MB were
full?  Checking malloc returns cannot suffice.