Den 16-Mar-00 16:08:24 skrev James Sutherland fĝlgende om "Re: Overcommitable memory??":
> On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
> You can still run out of memory, with or without COW, overcommit etc. I
> think we are talking at cross purposes here: By running out of memory, I
> mean there isn't any free memory to give to apps requesting it (via
> malloc() etc.)
Right. See below.
> If Netscape blows up and grabs all my memory, other applications can't get
> any - so I have problems. I need Netscape to be killed to fix the problem
Lots of people participating in this discussion will tell you that apps
just die when they get a null return from malloc(), so the problem should
solve itself when Netscape gets null from malloc() and gives up.
Actually, just having overcommitment turned off will itself tend to keep
a little memory free for someone to log in and sort out the situation.
Let's say the system is down to 500 kB of free memory (RAM+swap) and a
program requests 600 kB. Now, without overcommitment of memory, the
allocation will fail and the system will still have 500 kB of free memory
left, all your daemons will still be running, etc. You'd need a malicious
program behaviour to run the system completely out of memory. If however,
memory is overcommitted, the program will be allowed to use more memory and
gradually eat away memory, one page at a time, until there is not even a
single free page left in the system, at which point the OOM killer has to
kill one or more processes, possibly some that were doing just fine with
the memory they had already allocated. Any program, including well behaved
ones, could cause that situation.
> - and I can't log in to do it manually. THIS is the OOM situation I am
> thinking of, not a kernel-level problem of being unable to handle a page
> fault.
Right. Two different kinds of OOM situations are:
1) Applications can't allocate memory because malloc() (or any other memory
allocation mechanism) fails. It is a real possibility, and applications
will have to be able to deal with it. Preventing this situation from taking
a system down is a question of system administration.
2) An application accesses a part of its allocated address space and the
kernel can't handle it because all RAM and swap has been used. This can
only happen when the kernel has overcommitted memory. Short of suspending
the currently running process until memory is freed, there isn't much the
kernel can do except to kill a process and free memory that way.
Since 2) can be avoided simply by not overcommitting memory, it should
at least be possible to turn it off.
Regards,
/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.dtu.dk |
| Please do NOT Cc: to me or the | WWW: http://www.gbar.dtu.dk/~c948374/ |
| mailing list. I am on the list.| "ThrustMe" on XPilot, ARCnet and IRC |
| "Compatible": Gracefully accepts erroneous data from any source. |
-
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:28 EST