> Shaun Wilson wrote:
> >
> > On Tue, 6 Oct 1998, Stephen C. Tweedie wrote:
> >
>
> I'm sorry, but I have to disagree.
>
> to see that could be a solution for a long standing Linux problem (at
> least in my "user" vision): when the system got oom we can't even log in
> to solve the problem. (can't map libxxxx error). This situations was not
I'm not talking of the OOM killer. I'm was wondering why programs don't
handle oom on a by-program basis as you might think is normal. I think
that it *is* an improvement. not perfect, but an improvement
none-theless. I share your same view.
>
> 2) I don't understand why OOM Killer in the kernel can be such a bad
> thing. If you don't want/need it, just disable it in the kernel config.
>
I hope everyone see this. Some message someone suggested an 'official
kernal patch site' or simlar, where such patches could be easily
distributed, tested and the like. I think that would work nicely for
things such as Rik's OOM killer. Allowing it an option to those who
know it's there. Of course, direct inclusion to the kernel may not be
such a bad idea, except that even *i* think there must abe a better
solution for an oom event than to just arbitrily kill off offending
processes (yes, flame me, that is what the admin will do anyway) but you
cannot get code to completely sim. a human. You can try, you may even
get REALLY close if you ignore 'security holes' in the initial stages.
> 4) I think Rik's approach is right and that Andrea's patch is a very
> good effort also. I don't think that we can say how a user must use the
> system, I think the user (maybe we) must have options to trigger a
> feature on or off as she/he needs.
I agree. I agree. I agree. I agree.
But it still seems wrong. Am I the only one thinking this way? (No
offense Rik. As you mentioned afore there are/is dependant programs that
would prevent a simpler oom handling 'model'. Sounds to me like a badly
designed application that is assuming too much about too little, but..)
Just ignore me though, I am *not* an mm guru, and it'll be next week
before I'll be able to tackle the subject with half a brain.
-
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/