Re: [PATCH] copy over oom_adj value at fork time

From: Paul Menage
Date: Tue Jul 14 2009 - 21:16:00 EST


On Tue, Jul 14, 2009 at 6:05 PM, Rik van Riel<riel@xxxxxxxxxx> 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@xxxxxxxxxx>
> Reported-by: Paul Menage <manage@xxxxxxxxxx>
> ---
> 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")

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).

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/