lkml.org 
[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Avoiding OOM on overcommit...?
John Ripley wrote:
> The whole point is: in a system without overcommit, a process is never
> killed for overcommitting.
---
Exactly. *Deciding* what processes to kill is an administrative
*policy*. It shouldn't be an automatic kernel function except as an extension.

I feel safer running an application on a system that I know will either
deny resources that aren't present or suspend a process that can't be given
a denial. Then I know what is happening in my "state machine".

I'm trying to think about what cases would need to be caught to
enable this type of integrity.

On a fork, COW pages would have to be 'committed'. This implies
we need to have a committed page count in addition to a free page count.
Same for pages committed by brk/sbrk. Stack -- we'd need to decide on
behavior -- maybe the decision is you start with 1 page, and if you run out
of free pages and need more stack we use a signal. Default is to die. User
can set to ignore, in which case, the process is suspended until its request
can be fulfilled -- go to sleep waiting for free memory. Optionally, program
developer could specify a default stack size at link time that would
'commit' the specified memory.

If we get the bookkeeping correct, then to add 'virtual swap', we
just bump the 'free' count above what is physically available. Same behavior
as above if you are running overcommitted and you run out of memory.

What other system calls/functions overcommit?
-l
--
Linda A Walsh | Trust Technology, Core Linux, SGI
law@sgi.com | Voice: (650) 933-5338
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site