On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
> Den 13-Mar-00 22:26:50 skrev James Sutherland følgende om "Re: Overcommitable memory??":
> > On Mon, 13 Mar 2000, Michael Bacarella wrote:
>
> >> The way I see it, apps that have successfully allocated memory in the past
> >> wouldn't start dying since there's no malloc() to fail, wheras new apps
> >> that want to bring down the system will start getting failed
> >> malloc()/mmap()'s
>
> > Except many apps DO allocate memory during run time for buffers, workspace
> > etc. That's why, at present, lots of processes start dropping dead once
> > malloc() starts failing.
>
> For at large number of programs, this probably _is_ the right thing to
> do.
Except that the process failing is probably NOT the cause of the problem.
If your application causes problems on the server, I want it to be YOUR
application which dies as a result - not all the other ones!
> >> 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.
No, we have GIVEN it 256K of RAM. We don't say "We've got 255Mb of RAM,
how much would you like?", the app says "I need 17384Kb of RAM to operate.
Can I have it please?". Either the kernel says "yes", and it works, or it
says "no", and the app gives up.
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.
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.
James.
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:17 EST