From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <07ee3c188fbd29d5ca5bcc7fb664a9d1@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 overcommits memory?
Date: Mon,  3 Sep 2007 10:01:10 -0400
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <45ca7714d57ed4cc0c590e031559678d@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: b53c4304-ead2-11e9-9d60-3106f5b1d025

>> If system calls were the only way to change memory allocation, one
>> could probably keep a strict accounting of pages allocated and fail
>> system calls that require more VM than is available.  But neither Plan
>> 9 nor Unix works that way.  The big exception is stack growth.  The
>> kernel automatically extends a process's stack segment as needed.  On
>> the pc, Plan 9 currently limits user-mode stacks to 16MB.  On a CPU
>> server with 200 processes (fairly typical), that's 3.2GB of VM one
>> would have to commit just for stacks.  With 2,000 processes, that
>> would rise to 32GB just for stacks.
>
> 16MB for stacks seems awful high to me.  are there any programs that
> need even 1/32th of that?  512k is still 32k levels of recursion of
> a function needing 4 long arguments.  a quick count on my home machine
> and some coraid servers don't show any processes using more than 1
> page of stack.
>
> doing strict accounting on the pages allocated i think would be an
> improvement.  i also don't see a reason not to shrink the maximum
> stack size.
>
> the current behavior seems pretty exploitable to me.  even remotely,
> if one can force stack/brk allocation via smtp, telnet or whatnot.
>
> - erik

Most applications probably use much less than 1 MB, but a lot depends
on who wrote the program.  Our threaded programs typically have a 4K
or 8K (K, not M) fixed-size stack per thread and that works fine,
although you have to remember not to declare big arrays/structs as
local variables.  malloc and free become good friends in threaded
programs.

As to guarantees that you won't run our of memory, they're almost
impossible to give.  Programmer generally don't know how much memory
their applications will use, so they can't reasonably preallocate.

You see the same thing with real time.  Nobody knows how much time
each task will consume beforehand.

It would be cool to be able to get a handle on being able to shrink
the memory occupied by an application dynamically.  Malloc (through
brk()) grows the memory footprint, but free does not shrink it.
The same is true for the stack.  Once allocated, it doesn't get freed
until the process exits.

	Sape