RE: Avoiding *mandatory* overcommit...

From: Jesse Pollard (pollard@cats-chateau.net)
Date: Thu Mar 30 2000 - 19:30:59 EST


On Thu, 30 Mar 2000, David Schwartz wrote:
>> ??? But this is known. If a process mallocs 1 Meg of memory, you
>> commit (reserve) one meg of physical memory/swap. If a process
>> does an exec,
>> you 'commit' (reserve) exactly all of the COW pages. In the case
>> of stack,
>> the user or sysadmin sets a minimum stack to run with -- lets say 128K or
>> 1M -- whichever. That is the amount reserved. Then when I write reliable
>> process, that limits it's stack usage to < the reserved value --
>> every call
>> will return a reliable indicator "pass or fail". Never will I just be
>> 'killed' because the system couldn't map memory it had already allocated
>> to me.
>
> Okay, so suppose you are using only memory you are allowed to use. Later
>on, the system runs out of memory and swap. Your process touches one of its
>pages that has been swapped out. The system must page in that page for you
>in order for your process to continue running. The system, unfortunately,
>cannot page in for your process since it can't page out because swap is
>full. Please tell me what the system should do other than kill your process.

If all processes are obeying the same rule, they get paged out to the space
allocated to them. If you are overcommited as your statement indicates then
your system is unreliable. The results could be:

a. put process to sleep, waiting for memory. Disable user forks, disable exec,
   (disabling exec will usually free up memory, disabling forks usually frees
    up even more, disabling brk, stack allocations, and mmap will usually
    free up enough to wake the process waiting for memory.) MOST programs are
        not programmed well enough to handle having memory allocation disallowed
         this way.
b. abort the other process.
c. abort the current process.

> Don't forget, if you disable overcommit, you are likely to run out of
>memory+swap much, MUCH sooner. You had better have a good way to deal with
>that other than killing processes.

I would much prefer the process never starting because there is insufficient
resources available, over starting and getting half-way through updating
files and getting aborted.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:28 EST