Messages in this thread | | | Date | Tue, 6 Oct 1998 22:21:07 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: Out Of Memory in v. 2.1 |
| |
On Tue, 6 Oct 1998, Shaun Wilson wrote:
> With the recent discussion of OOM and killers, why again was it a bad > thing to just return a NULL upon a memory request that would otherwise > fail? Isn't this by definition to way xalloc() operates?
Memory allocation isn't always done by malloc()/brk(). Memory also needs to be allocated when an mmap()ed region has a pagefault or when the in-kernel TCP stack needs memory. You can't really return NULL to one of these situations, can you?
It could mean killing init because netscape gobbled up the rest of the memory -- indirectly resulting in killing netscape after all. In cases like this, it is better to kill the worst offender and avoid killing: - critical daemons - the rest of the system - the worst offender after all (in a more indirect way)
> It seems to me that if there is a program out there that is not > written to act accordingly to a NULL pointer upon a memory alloc > request then it's time the program was repaired.
A program doing a malloc()/brk() isn't the only place where memory is allocated!
> My only fear about having 'OOM killer-liek code' in the kernel is > what if something important attempts to allocate memory that does > not exist? Such as a very important cron-job, or something that > would be devastating to the system if just killed (fsck OOM?)
That is why I made the OOM code -- to avoid killing harmless and/or important jobs. With Andrea's code and the standard kernel you will end up killing a more or less random task. My code tries to select the worst offender and kill that.
> You can't expect the kernel to come up with a better method of > handling out of memory. There is no one solution to oom for every > program other than to let every program handle the situation itself > as deemed necessary by the programs author.
Memory is not allocated upon malloc() and programs depend on that (sparse memory usage). Memory is allocated upon a page fault -- then it's too late to send a signal to the program.
> And as per the remark on 'a malicious attempt' this is unaviodable even > if teh oom code is modified. If joe-user allocates all available memory > then all new processes WILL fail until the admin goes, hey, look at this > app here eating 80% of the 512MB memory, oh gee how odd "kill <pid>". > > Arbitrarily or even decisively killing processes is not the answer.
Letting the sysadmin do the kill is often just as arbitrarily and/or decisively as the kernel does -- it's an emergency situation and fast action is required.
The advantage of doing it in kernel mode is that you are guaranteed to be able to actually proceed with the killing, you avoid manual intervention and you can do the selection about as good as a human sysadmin who is faced with an emergency situation.
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- 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/
| |