Messages in this thread | | | Date | Sun, 18 Jan 2009 23:41:00 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [why oom_adj does not work] Re: Linux killed Kenny, bastard! |
| |
On Sun, Jan 18, 2009 at 09:25:49PM +0100, Bodo Eggert (7eggert@gmx.de) wrote: > > It is not about who should not be killed, but who should _be_ in the > > first raw. > > If it comes to the killing, it will start with the first row, or using your > patch, with the only man in the first row, named kenny. Now imagine a > phalanx of spawned kennies protecting a running-wild application from being > killed ... > > If you set the oom_adj to mark the goat under normal conditions, the system > will adjust itself to abnormal conditions.
Admin who sets is up knows what he is doing. Hope you will not argue about the case, when admin will disable the oom-killer and will not be able to log in.
Once again: this is an additional tunable which allows to easily solve the problem showed here multiple times. And whily you did not try to tune oom-adj yourself you continue arguing that it works the best. It does not. Any solution for the showed problem is not a simple and nice-looking, the one I proposed imo looks the most convenient for the people who really work with the systems where described behaviour was observed.
> > > > No, admin will limit/forbid the connection from the DoSing clients, > > > > server must always live to handle proper users. > > > > > > If there is no memory, the admin can't even log in. > > > > Admin can observe the situation via kvm or sometimes netconsole and > > tune the system for the next run. > > So your kill-kenny does not only require having exactly one goat system-wide > and no process having the same process name, but also constant supervision. > I think it's a really great design!
You should reread (better twice) what we are talking about here and what and why patch was proposed. And how it works too.
-- Evgeniy Polyakov
| |