[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.0.999.0901181333160.6179@be1.lrz>
Date: Sun, 18 Jan 2009 13:37:09 +0100 (CET)
From: Bodo Eggert <7eggert@....de>
To: Evgeniy Polyakov <zbr@...emap.net>
cc: Bodo Eggert <7eggert@....de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Dave Jones <davej@...hat.com>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [why oom_adj does not work] Re: Linux killed Kenny, bastard!
On Sat, 17 Jan 2009, Evgeniy Polyakov wrote:
> On Sat, Jan 17, 2009 at 03:12:49PM +0100, Bodo Eggert (7eggert@....de) wrote:
> > > > > This does not work if processes are short-living and are spawned by the
> > > > > parent on demand.
> > > >
> > > > They will have the same name, too. Your Kenny-killer will fail, too.
> > >
> > > It is not always the case, processes start executing different binaries
> > > and change the names, that's at least what I observed in the particular
> > > root case of the discussion.
> >
> > In that case, you can use a wrapper script.
>
> That may be a solution, except that not very convenient, since there may
> be really lots of executables and cooking up a special script for
> everyone will not scale well.
How many different CGI handlers are you going to have?
And how does kill-kenny scale with the number of users on the system?
I want my browser not to be killed, while the other user wants his
gimp not to be killed. As you can see, it does not even scale for
the most simple multi-user system.
> > > There could be lots of heuristics applied for the different cases, but
> > > without changing the application, they are somewhat limited to
> > > long-living processes only. There are really lots of cases when it does
> > > not stand.
> >
> > If it's short-lived enough, the processes will out-die the OOM-Killer.
> > You can only win by by suspending or killing the factory.
>
> 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.
--
Programming is an art form that fights back.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists