Messages in this thread | | | Date | Wed, 14 Oct 1998 18:18:22 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 2.1.125 Show stopper list: Draft |
| |
On Wed, 14 Oct 1998, Rik van Riel wrote:
>It's not a feature, it is a check to make certain we >really are out of memory before calling oom(tsk).
This make no sense. The real disaster is caused by __get_free_pages() that returns NULL. Once it returns NULL and it' s been recalled to alloc a page for a process mmap you must kill the process (or at least another one that has at least some page alloced and try again).
Obviously you never seen a failed process allocation because:
1. the kernel just deadlocked. 2. your OOM killer has just killed one process before __get_free_pages() had the time to fail (note that you had to put the oom check in kswapd that is the only thing running at that time).
And note that if you have not changed the force_sig() from linux/mm/*.c in your patch, and your patch works fine, you have proved what I said!
So your whole OOM killer patch is a screw up of the linux mm. It' s far from fix the deadlock.
>chance of that happening is increased from virtually >impossible to just very unlikely, but the chance of the >bug manifesting itself _has_ increased with your patch.
Your OOM hide the deadlock. This is a bug.
>It almost seems like a bug doesn't exist until you can >see it with your own eyes -- this is a completely >unacceptable point of view since we are programming >code that is to be used by millions of users on thousands >of different hardware/load combinations.
Infact I am wating for bug reports.
>When programming for such a wide usage pattern, we >just _have_ to take theoretical bugs into account >as well... (QED)
This is why I don' t want your patch that leave the dealock OOM bug in the kernel.
And note that the mm layer must be stable, not deadlock, not cause starvation, must be efficient, and must work in the most of cases (it has not to be perfect, it can' t be perfect since phys memory is finite and all algorithms are heuristic). I am not sure to be right here but sure this is my thought.
Andrea Arcangeli
- 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/
| |