[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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?
Linda A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.084 / U:1.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site