From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Shakeel Butt <shakeelb@google.com>, linux-mm@kvack.org
Subject: Re: [PATCH] mm: mempolicy: don't select exited threads as OOM victims
Date: Tue, 2 Jul 2019 15:51:48 +0200 [thread overview]
Message-ID: <20190702135148.GF978@dhcp22.suse.cz> (raw)
In-Reply-To: <0d81f46e-0b5f-0792-637f-fa88468f33cf@i-love.sakura.ne.jp>
On Tue 02-07-19 22:19:27, Tetsuo Handa wrote:
> On 2019/07/01 23:16, Michal Hocko wrote:
> > Thinking about it some more it seems that we can go with your original
> > fix if we also reorder oom_evaluate_task
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index f719b64741d6..e5feb0f72e3b 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -318,9 +318,6 @@ static int oom_evaluate_task(struct task_struct *task, void *arg)
> > struct oom_control *oc = arg;
> > unsigned long points;
> >
> > - if (oom_unkillable_task(task, NULL, oc->nodemask))
> > - goto next;
> > -
> > /*
> > * This task already has access to memory reserves and is being killed.
> > * Don't allow any other task to have access to the reserves unless
> > @@ -333,6 +330,9 @@ static int oom_evaluate_task(struct task_struct *task, void *arg)
> > goto abort;
> > }
> >
> > + if (oom_unkillable_task(task, NULL, oc->nodemask))
> > + goto next;
> > +
> > /*
> > * If task is allocating a lot of memory and has been marked to be
> > * killed first if it triggers an oom, then select it.
> >
> > I do not see any strong reason to keep the current ordering. OOM victim
> > check is trivial so it shouldn't add a visible overhead for few
> > unkillable tasks that we might encounter.
> >
>
> Yes if we can tolerate that there can be only one OOM victim for !memcg OOM events
> (because an OOM victim in a different OOM context will hit "goto abort;" path).
You are right. Considering that we now have a guarantee of a forward
progress then this should be tolerateable (a victim in a disjoint
numaset will go away and other one can go ahead and trigger its own
OOM).
> Thinking again, I think that the same problem exists for mask == NULL path
> as long as "a process with dying leader and live threads" is possible. Then,
> fixing up after has_intersects_mems_allowed()/cpuset_mems_allowed_intersects()
> judged that some thread is eligible is better.
This is getting more and more hair for something that is not really
clear to be an actual problem. Don't you think?
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index d1c9c4e..43e499e 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -109,8 +109,23 @@ static bool oom_cpuset_eligible(struct task_struct *start,
> */
> ret = cpuset_mems_allowed_intersects(current, tsk);
> }
> - if (ret)
> - break;
> + if (ret) {
> + /*
> + * Exclude dead threads as ineligible when selecting
> + * an OOM victim. But include dead threads as eligible
> + * when waiting for OOM victims to get MMF_OOM_SKIP.
> + *
> + * Strictly speaking, tsk->mm should be checked under
> + * task lock because cpuset_mems_allowed_intersects()
> + * does not take task lock. But racing with exit_mm()
> + * is not fatal. Thus, use cheaper barrier rather than
> + * strict task lock.
> + */
> + smp_rmb();
> + if (tsk->mm || tsk_is_oom_victim(tsk))
> + break;
> + ret = false;
> + }
> }
> rcu_read_unlock();
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-07-02 13:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 11:24 [PATCH] mm: mempolicy: don't select exited threads as OOM victims Tetsuo Handa
2019-07-01 11:17 ` Michal Hocko
2019-07-01 13:04 ` Tetsuo Handa
2019-07-01 13:17 ` Michal Hocko
2019-07-01 13:38 ` Tetsuo Handa
2019-07-01 13:48 ` Michal Hocko
2019-07-01 13:56 ` Tetsuo Handa
2019-07-01 14:04 ` Michal Hocko
2019-07-01 14:16 ` Michal Hocko
2019-07-02 13:19 ` Tetsuo Handa
2019-07-02 13:51 ` Michal Hocko [this message]
2019-07-02 21:26 ` Tetsuo Handa
2019-07-03 7:06 ` Michal Hocko
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=20190702135148.GF978@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=shakeelb@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.