lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Overcommitable memory??
In <1553.109T1700T8214192rask@kampsax.k-net.dk> Rask Ingemann Lambertsen (rask@kampsax.k-net.dk) wrote:
>>> There's no reason to tell an application that it has X megs of memory all
>>> to itself to play with, and then KILL one of it's brothers if the kernel
>>> finds itself short.

>> We don't "tell" any application we have X Mb of RAM.

> Actually, we do. If malloc (262144) returns non-zero, then we've told
> the application that we have 256 kB of memory, implemented as RAM or swap
> in any combination the kernel sees fit, as long as there is 256 kB in total.

And it's WRONG thing to do. Take my sample: there are 10 processes allocated
1000MiB together even if there are only 128MiB in system. So in the end kernel
will be unable to fullfill promise for one of that 10 processes. Still I can
not allocate 500MiB in one process since there are "not enough memory". Looks
VERY weird to me: I can not write old-fashioned program will few HUGE
preallocated arrays since "there are not enough RAM" and still malloc will
happily overcommit memory badly so in the end this protection buys you nothing.
Why it was implemented this way ?




-
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    [W:0.209 / U:2.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site