mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com, Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	rientjes@google.com, mel@csn.ul.ie, npiggin@suse.de
Subject: Re: [PATCH] copy over oom_adj value at fork time
Date: Wed, 15 Jul 2009 11:01:59 +0900 (JST)	[thread overview]
Message-ID: <20090715104920.39A4.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <6599ad830907141815x64e74a6ek1499f6032cea6f5@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2401 bytes --]

> On Tue, Jul 14, 2009 at 6:05 PM, Rik van Riel<riel@redhat.com> wrote:
> > After moving the oom_adj value from the task struct to the
> > mm_struct, the oom_adj value was no longer properly inherited
> > by child processes.
> >
> > Copying over the oom_adj value at fork time fixes that bug.
> >
> > Signed-off-by: Rik van Riel <riel@redhat.com>
> > Reported-by: Paul Menage <manage@google.com>
> > ---
> > Paul, does this fix your bug?
> 
> It fixes that specific problem. (Although the patch title should
> probably be "copy over oom_adj value at execve time")

AFAIK mm_init() is called from both fork() and execve().


> But ironically, with this fix applied the main part of the original
> change (force all threads in a process to share a single oom_adj
> value) will start to break my code - it's no longer possible to have
> the regular threads in a process be oom-immune, then vfork() and set a
> non-disabled oom_adj in the child, since this will set it for the
> entire process. (Our job scheduler does something like this, in order
> to have the launcher be OOM immune and the running jobs be at various
> oom_adj levels depending on their priority).

Fair point.
Nobody want per-thread oom_adj, but your vfork() issue seems real regression.

David, can we make more clever implementation?

> 
> It's probably something that I can work around, but it seems like the
> kind of API change that could break unsuspecting users.
> 
> Paul
> 
> >
> >  kernel/fork.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > Index: mmotm/kernel/fork.c
> > ===================================================================
> > --- mmotm.orig/kernel/fork.c    2009-07-14 20:58:01.000000000 -0400
> > +++ mmotm/kernel/fork.c 2009-07-14 21:00:40.000000000 -0400
> > @@ -435,6 +435,7 @@ static struct mm_struct * mm_init(struct
> >        init_rwsem(&mm->mmap_sem);
> >        INIT_LIST_HEAD(&mm->mmlist);
> >        mm->flags = (current->mm) ? current->mm->flags : default_dump_filter;
> > +       mm->oom_adj = current->mm->oom_adj;
> >        mm->core_state = NULL;
> >        mm->nr_ptes = 0;
> >        set_mm_counter(mm, file_rss, 0);
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/




  reply	other threads:[~2009-07-15  2:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200906020557.n525v6KO004302@imap1.linux-foundation.org>
2009-07-15  0:52 ` + oom-move-oom_adj-value-from-task_struct-to-mm_struct.patch added to -mm tree Paul Menage
2009-07-15  1:05   ` [PATCH] copy over oom_adj value at fork time Rik van Riel
2009-07-15  1:15     ` Paul Menage
2009-07-15  2:01       ` KOSAKI Motohiro [this message]
2009-07-15  2:12         ` [PATCH -mm] copy over oom_adj value at fork time (v2) Rik van Riel
2009-07-15  3:42           ` David Rientjes
2009-07-15  3:48       ` [PATCH] copy over oom_adj value at fork time David Rientjes
2009-07-16 23:29       ` Paul Menage
2009-07-17  9:34         ` David Rientjes
2009-07-17 20:03           ` Paul Menage
2009-07-17 23:12             ` David Rientjes
2009-07-20 21:52               ` Paul Menage
2009-07-21  3:40                 ` David Rientjes
2009-07-21  7:19                 ` KOSAKI Motohiro
2009-07-21 16:06                   ` Paul Menage
2009-07-21 19:54                     ` David Rientjes
2009-07-21 19:57                       ` Paul Menage
2009-07-21 20:00                         ` David Rientjes
2009-07-21 20:03                           ` Paul Menage
2009-07-23 23:21                             ` KOSAKI Motohiro
2009-07-23 23:29                               ` David Rientjes
2009-07-24  1:10                                 ` KOSAKI Motohiro
2009-07-24  9:27                                   ` David Rientjes
2009-07-28  6:09                                     ` KOSAKI Motohiro
2009-07-28  6:14                                       ` David Rientjes
2009-07-15  1:49     ` KOSAKI Motohiro

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=20090715104920.39A4.A69D9226@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=menage@google.com \
    --cc=npiggin@suse.de \
    --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

all inboxes | Powered by JetHome®