On 20 Mar 2000 15:34:19 +0100, you wrote:
>Den 15-Mar-00 23:36:21 skrev James Sutherland følgende om "Re: Overcommitable memory??":
>> On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
>>> Den 13-Mar-00 22:26:50 skrev James Sutherland følgende om "Re:
>>> Overcommitable memory??":
>>> > 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
>> No, we have GIVEN it 256K of RAM.
> Yes! We've promised the program that it has those 256 kB all to
>itselves. This means that the system must have this memory at all times in
>some shape or form until the program free()s it.
To be precise, we have given it 256K of address space (a sparse
matrix). This matrix will then be populated if and when the process
If you want a fully populated area, just touch it. End of problem.
>> The problems occur when it decides it would like another chunk of RAM, and
>> is told it can't have it - at which point (since it only asked because it
>> NEEDED the RAM) it will almost always have to give up.
> This is very application dependent. For example, to inetd, memory
>allocation failure just means that it can't launch external servers and
>will have to postpone reloading of its config file. As long as no OOM
>killer comes along inetd's way, it will do fine unless coded in a stupid
>way. The latter possibility isn't a kernel issue.
>> We NEVER allocate memory via malloc() and then later discover we can't
>> honour that allocation - once the memory has been allocated, it is the
>> property of that process, to do with as it pleases.
> Not when overcommitting memory. That's the whole problem, and why I want
>it to be possible to turn off overcommitment of memory completely.
Unfortunately, this would break a lot of code which would depend on
the current (perfectly reasonable) implementation of malloc() and
stack space - namely, memory is only allocated when you use it.
If you really want your code to occupy unused space, just touch the
space when you allocate it. End of problem.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:30 EST