From: Edjard Souza Mota <edjard@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Ilias Biris <xyz.biris@gmail.com>,
tglx@linutronix.de, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
Andrew Morton <akpm@osdl.org>, Andrea Arcangeli <andrea@suse.de>
Subject: Re: User space out of memory approach
Date: Wed, 12 Jan 2005 11:31:47 +0200 [thread overview]
Message-ID: <4d6522b9050112013123535a0b@mail.gmail.com> (raw)
In-Reply-To: <1105477069.17853.126.camel@tglx.tec.linutronix.de>
Hi,
On Tue, 11 Jan 2005 21:57:49 +0100, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 2005-01-11 at 16:46 -0400, Ilias Biris wrote:
> > well looking into Alan's email again I think I answered thinking on
> > the wrong side :-) that the suggestion was to switch off OOM
> > altogether and be done with all the discussion... tsk tsk tsk too
> > defensive and hasty I guess :-)
> >
> > Thinking it in another way alan's email could have the dimension of
> > switching off overcommitment (and thus OOM) whilst in the user-space
> > ranking stage to avoid reentrancy and invocation of oom again and
> > again before killing something. It also solves the issue of using
> > timed/counted resources which is plain ugly and evil. It would though
> > be necessary to switch OOM back on when the OOMK has finally done the
> > kill.
> >
> > Did I get it right this time Alan?
>
> I don't get it at all.
>
> Fixes for wrong invocation, reentrancy avoidance, removal of the ugly
> and evil timer,counter hacks are in the wild since more than 6 weeks.
> They solve the problem without any userspace interaction.
>
> The userspace provided preferrable victim list is an improvement of the
> generic heuristic and therefor imperfect selection mechanism and nothing
> else.
Once again the user space ranking of PIDs for OOM killer purposes didn't
propose a new selection mechanism. This misinterpretation is misleading the
discussion of whether it may have som use in embedded devices or not.
Even though, I believe that for PCs environment it has a great potential
when you think that admins don't stay all the time in front of a computer.
Once and while they also have a rest :). In these cases, instead of simply
start ranking a deamon could dispatch a msg to her/him saying the system
is approaching a red zone.
br,
Edjard
--
"In a world without fences ... who needs Gates?"
next prev parent reply other threads:[~2005-01-12 9:31 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-10 21:43 User space out of memory approach Mauricio Lin
2005-01-10 19:20 ` Marcelo Tosatti
2005-01-10 19:39 ` Marcelo Tosatti
2005-01-10 23:01 ` Mauricio Lin
2005-01-10 22:40 ` Edjard Souza Mota
2005-01-10 20:05 ` Marcelo Tosatti
2005-01-10 23:17 ` Edjard Souza Mota
2005-01-10 23:18 ` Edjard Souza Mota
2005-01-10 23:24 ` Mauricio Lin
2005-01-10 23:30 ` Mauricio Lin
2005-01-11 7:47 ` Marcelo Tosatti
2005-01-11 0:35 ` Thomas Gleixner
2005-01-11 2:03 ` Edjard Souza Mota
2005-01-11 8:44 ` Thomas Gleixner
2005-01-11 8:58 ` Andrea Arcangeli
2005-01-11 7:48 ` Marcelo Tosatti
2005-01-11 9:08 ` Andrew Morton
2005-01-11 9:19 ` Andrea Arcangeli
2005-01-11 9:27 ` Andrew Morton
2005-01-11 9:20 ` Edjard Souza Mota
2005-01-11 9:30 ` Thomas Gleixner
2005-01-11 9:56 ` Andrea Arcangeli
2005-01-11 10:05 ` Edjard Souza Mota
2005-01-11 10:39 ` Thomas Gleixner
2005-01-11 10:44 ` Andrea Arcangeli
2005-01-11 14:56 ` Edjard Souza Mota
2005-01-11 15:27 ` Ilias Biris
2005-01-11 10:00 ` Edjard Souza Mota
2005-01-11 10:36 ` Thomas Gleixner
2005-01-11 16:32 ` Alan Cox
2005-01-11 19:16 ` Ilias Biris
2005-01-11 20:46 ` Ilias Biris
2005-01-11 20:57 ` Thomas Gleixner
2005-01-12 9:31 ` Edjard Souza Mota [this message]
2005-01-12 11:19 ` Thomas Gleixner
2005-01-12 12:12 ` Edjard Souza Mota
2005-01-13 15:36 ` Alan Cox
2005-01-16 10:06 ` Edjard Souza Mota
2005-01-16 21:10 ` Alan Cox
2005-01-17 10:16 ` Thomas Gleixner
2005-01-11 21:35 ` Denis Vlasenko
2005-01-11 20:40 ` Thomas Gleixner
2005-01-11 7:42 ` Marcelo Tosatti
2005-01-11 10:51 ` Thomas Gleixner
2005-01-11 11:03 ` Andrea Arcangeli
2005-01-11 8:38 ` Andrea Arcangeli
2005-01-21 21:27 ` Mauricio Lin
2005-01-21 21:45 ` Mauricio Lin
2005-01-22 3:32 ` Andrea Arcangeli
2005-01-25 21:13 ` Mauricio Lin
2005-01-25 21:39 ` Thomas Gleixner
2005-01-26 0:11 ` Mauricio Lin
2005-01-26 0:49 ` Andrea Arcangeli
2005-01-26 14:03 ` Mauricio Lin
2005-01-27 18:54 ` Mauricio Lin
2005-01-27 22:11 ` Andrea Arcangeli
2005-01-27 22:29 ` Andrew Morton
2005-01-27 22:58 ` Andrea Arcangeli
2005-01-27 23:35 ` Andrew Morton
2005-01-28 0:15 ` Andrea Arcangeli
2005-01-28 13:58 ` Mauricio Lin
2005-01-28 15:21 ` Mauricio Lin
2005-01-28 15:29 ` Andrea Arcangeli
2005-01-26 7:26 ` Thomas Gleixner
2005-01-22 3:04 ` Andrea Arcangeli
[not found] <fa.lcmt90h.1j1scpn@ifi.uio.no>
[not found] ` <fa.ht4gei4.1g5odia@ifi.uio.no>
2005-01-16 16:28 ` Bodo Eggert
2005-01-18 13:15 ` Edjard Souza Mota
2005-01-19 6:18 ` Bodo Eggert
2005-01-20 3:20 ` Edjard Souza Mota
2005-01-20 5:00 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d6522b9050112013123535a0b@mail.gmail.com \
--to=edjard@gmail.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=tglx@linutronix.de \
--cc=xyz.biris@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).