> 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/