From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Mauricio Lin <mauriciolin@gmail.com>
Cc: Edjard Souza Mota <edjard@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: User space out of memory approach
Date: Tue, 11 Jan 2005 05:47:22 -0200 [thread overview]
Message-ID: <20050111074722.GC18796@logos.cnet> (raw)
In-Reply-To: <3f250c71050110152421e83e04@mail.gmail.com>
On Mon, Jan 10, 2005 at 07:24:35PM -0400, Mauricio Lin wrote:
> On Mon, 10 Jan 2005 18:05:14 -0200, Marcelo Tosatti
> <marcelo.tosatti@cyclades.com> wrote:
> > On Tue, Jan 11, 2005 at 12:40:24AM +0200, Edjard Souza Mota wrote:
> > > Hi,
> > >
> > > I guess it the idea was not fully and well explained. It is not the OOM Killer
> > > itself that was moved to user space but rather its ranking algorithm.
> > > Ranking is not an specific functionality of kernel space. Kernel only need
> > > to know which process whould be killed.
> > >
> > > In that sense the approach is different and might be worth testing, mainly for
> > > cases where we want to allow better policies of ranking. For example, an
> > > embedded device with few resources and important different running applications:
> > > whic one is the best? To my understanding the current ranking policy
> > > does not necessarily chooses the best one to be killed.
> >
> > Sorry, I misunderstood. Should have read the code before shouting.
> >
> > The feature is interesting - several similar patches have been around with similar
> > functionality (people who need usually write their own, I've seen a few), but none
> > has ever been merged, even though it is an important requirement for many users.
> >
> > This is simple, an ordered list of candidate PIDs. IMO something similar to this
> > should be merged. Andrew ?
> >
> > Few comments about the code:
> >
> > retry:
> > - p = select_bad_process();
> > + printk(KERN_DEBUG "A good walker leaves no tracks.\n");
> > + p = select_process();
> >
> > You want to fallback to select_bad_process() if no candidate has been selected at
> > select_process().
> The idea is turn off the select_bad_process() and the new
> select_process() will get the list of pids to be killed from
> /proc/oom. But the ranking algorithms is the same, I mean is the Rik
> van Riel algorithm. Do you think it is worthwhile to maintain the
> select_bad_process (kernel space algorithm) if we have the
> select_process() function?
Yes, if select_process() fails (in case no process is on the candidate list), i
fallbacking to select_bad_process() is important I think.
> >
> > You also want to move "oom" to /proc/sys/vm/.
>
> This can be possible. Do you think that it is a good place to move the oom?
Yep.
next prev parent reply other threads:[~2005-01-11 10:51 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 [this message]
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
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=20050111074722.GC18796@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=edjard@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mauriciolin@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).