From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>, Paul Menage <menage@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch -mm v2] mm: introduce oom_adj_child
Date: Thu, 30 Jul 2009 19:02:16 +0900 [thread overview]
Message-ID: <20090730190216.5aae685a.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0907300219580.13674@chino.kir.corp.google.com>
On Thu, 30 Jul 2009 02:31:04 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> On Thu, 30 Jul 2009, KAMEZAWA Hiroyuki wrote:
>
> > 1. IIUC, the name is strange.
> >
> > At job scheduler, which does this.
> >
> > if (vfork() == 0) {
> > /* do some job */
> > execve(.....)
> > }
> >
> > Then, when oom_adj_child can be effective is after execve().
> > IIUC, the _child_ means a process created by vfork().
> >
>
> It's certainly a difficult thing to name and I don't claim that "child" is
> completely accurate since, as you said, vfork'd tasks are also children
> of the parent yet they share the same oom_adj value since it's an
> attribute of the shared mm.
>
> If you have suggestions for a better name, I'd happily ack it.
>
Simply, reset_oom_adj_at_new_mm_context or some.
> > 2. More simple plan is like this, IIUC.
> >
> > fix oom-killer's select_bad_process() not to be in deadlock.
> >
>
> Alternate ideas?
>
At brief thiking.
1. move oom_adj from mm_struct to signal struct. or somewhere.
(see copy_signal())
Then,
- all threads in a process will have the same oom_adj.
- vfork()'ed thread will inherit its parent's oom_adj.
- vfork()'ed thread can override oom_adj of its own.
In other words, oom_adj is shared when CLONE_PARENT is not set.
2. rename mm_struct's oom_adj as shadow_oom_adj.
update this shadow_oom_adj as the highest oom_adj among
the values all threads share this mm_struct have.
This update is done when
- mm_init()
- oom_adj is written.
User's
# echo XXXX > /proc/<x>/oom_adj
is not necessary to be very very fast.
I don't think a process which calls vfork() is multi-threaded.
3. use shadow_oom_adj in select_bad_process().
> > rather than this new stupid interface.
> >
>
> Well, thank you. Regardless of whether you think it's stupid or not, it
> doesn't allow you to livelock the kernel in a very trivial way when the
> oom killer gets invoked prior to execve() and the parent is OOM_DISABLE.
>
just plz consider more.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-07-30 10:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-29 4:27 David Rientjes
2009-07-29 23:13 ` Andrew Morton
2009-07-29 23:25 ` Paul Menage
2009-07-30 2:32 ` KOSAKI Motohiro
2009-07-30 7:06 ` David Rientjes
2009-07-31 6:47 ` KOSAKI Motohiro
2009-07-31 9:31 ` David Rientjes
2009-08-03 11:58 ` KOSAKI Motohiro
2009-08-03 12:12 ` KOSAKI Motohiro
2009-07-30 9:00 ` KAMEZAWA Hiroyuki
2009-07-30 9:31 ` David Rientjes
2009-07-30 10:02 ` KAMEZAWA Hiroyuki [this message]
2009-07-30 19:05 ` David Rientjes
2009-07-31 0:33 ` KAMEZAWA Hiroyuki
2009-07-31 6:50 ` KOSAKI Motohiro
2009-07-31 19:38 ` David Rientjes
2009-08-03 12:16 ` KOSAKI Motohiro
2009-07-31 9:36 ` David Rientjes
2009-07-31 10:49 ` KAMEZAWA Hiroyuki
2009-07-31 19:18 ` David Rientjes
2009-08-01 1:10 ` KAMEZAWA Hiroyuki
2009-08-01 20:26 ` David Rientjes
2009-08-03 1:42 ` KAMEZAWA Hiroyuki
2009-08-03 7:59 ` David Rientjes
2009-08-03 8:02 ` KAMEZAWA Hiroyuki
2009-08-03 8:08 ` David Rientjes
2009-08-03 8:45 ` KAMEZAWA Hiroyuki
2009-08-03 8:55 ` KAMEZAWA Hiroyuki
2009-08-03 12:19 ` KOSAKI Motohiro
2009-08-03 12:32 ` KOSAKI Motohiro
2009-08-03 12:21 ` KOSAKI Motohiro
2009-08-03 16:17 ` Paul Menage
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=20090730190216.5aae685a.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=riel@redhat.com \
--cc=rientjes@google.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