[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Avoiding OOM on overcommit...?
On Mon, 27 Mar 2000, Peter T. Breuer wrote:
>"A month of sundays ago David Whysong wrote:"

>> the stack still dynamically grows, you have to make sure that you never
>> use more than the preallocated backing store.
>> Is that right?
>Yes. But there is nothing to make sure of. I propose that the process
>cannot start unless it has the backing store for its rlimit available -
>and that that store will be bound to it by the kernel for its and it
>alones future use until death do it part.

You want to reserve up to the hard rlimit? That can be a LOT of memory per

A malloc that touches all pages and returns zero on SIGSEGV is
an elegant solution for the heap.

Pre-allocating swap space up to the stack rlimit works, so long as the
kernel handles the case where the rlimit is increased. But this is a less
elegant solution, because you waste some resources in the common case.

I realize I'm splitting hairs here, and root is allowed to kill the
system... but root can increase his hard rlimit.


David Whysong
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page -
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91

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.085 / U:10.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site