On Thu, 16 Mar 2000, David Whysong wrote:
> On Wed, 15 Mar 2000, James Sutherland wrote:
>
> >> > 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.
>
> This is not strictly true; see below.
Yes, I know - not an ideal situation really. Also largely unrelated to the
original thread :)
> >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.
>
> It depends on if you set /proc/sys/vm/overcommit_memory. The default state
> has malloc() return 0 if your program asks for more than the TOTAL amount
> of virtual memory (RAM+swap) on the machine. If you do "echo 1 >
> /proc/sys/vm/overcommit_memory" then you can successfully malloc()
> arbitrarily large memory regions.
Yes - Unix philosophy always involves giving the user lots of rope, and
superuser near-infinite amounts...
This isn't what the original thread was about, though. I was talking about
circumstances where the system has run out of memory - at which point
processes try to allocate more, and fail. (Or, in suicide mode, they
succeed in allocating memory they then can't use...) We need to do
something pretty drastic at this point, otherwise more or less everything
is going to die in the immediate future.
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:19 EST