Messages in this thread | | | Date | Tue, 6 Oct 1998 08:49:02 -0500 (CDT) | From | Shaun Wilson <> | Subject | Re: Out Of Memory in v. 2.1 |
| |
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?
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.
<clap clap clap> for the mm patch, it's a good thing. Mayeb not the best but a good thing nonetheless.
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?)
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.
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.
- 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/
| |