From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
akpm@linux-foundation.org, mgorman@suse.de, oleg@redhat.com,
torvalds@linux-foundation.org, hughd@google.com,
andrea@kernel.org, riel@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.
Date: Tue, 23 Feb 2016 13:34:58 +0100 [thread overview]
Message-ID: <20160223123457.GC14178@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1602221701170.4688@chino.kir.corp.google.com>
On Mon 22-02-16 17:06:29, David Rientjes wrote:
> On Thu, 18 Feb 2016, Michal Hocko wrote:
>
> > > Anyway, this is NACK'd since task->signal->oom_score_adj is checked under
> > > task_lock() for threads with memory attached, that's the purpose of
> > > finding the correct thread in oom_badness() and taking task_lock(). We
> > > aren't going to duplicate logic in several functions that all do the same
> > > thing.
> >
> > Is the task_lock really necessary, though? E.g. oom_task_origin()
> > doesn't seem to depend on it for task->signal safety. If you are
> > referring to races with changing oom_score_adj does such a race matter
> > at all?
> >
>
> oom_badness() ranges from 0 (don't kill) to 1000 (please kill). It
> factors in the setting of /proc/self/oom_score_adj to change that value.
> That is where OOM_SCORE_ADJ_MIN is enforced.
The question is whether the current placement of OOM_SCORE_ADJ_MIN
is appropriate. Wouldn't it make more sense to check it in oom_unkillable_task
instead? Sure, checking oom_score_adj under task_lock inside oom_badness will
prevent from races but the question I raised previously was whether we
actually care about those races? When would it matter? Is it really
likely that the update happen during the oom killing? And if yes what
prevents from the update happening _after_ the check?
If for nothing else oom_unkillable_task would be complete that way. E.g.
sysctl_oom_kill_allocating_task has to check for OOM_SCORE_ADJ_MIN
because it doesn't rely on oom_badness and that alone would suggest
that the check is misplaced.
That being said I do not really care that much. I would just find it
neater to have oom_unkillable_task that would really consider all the
cases where the OOM should ignore a task.
--
Michal Hocko
SUSE Labs
--
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:[~2016-02-23 12:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 14:31 Tetsuo Handa
2016-02-17 14:48 ` Michal Hocko
2016-02-17 22:31 ` David Rientjes
2016-02-18 8:09 ` Michal Hocko
2016-02-18 10:30 ` Tetsuo Handa
2016-02-18 12:08 ` Michal Hocko
2016-02-18 12:13 ` Michal Hocko
2016-02-19 15:07 ` Tetsuo Handa
2016-02-19 15:13 ` Michal Hocko
2016-02-23 1:06 ` David Rientjes
2016-02-23 12:34 ` Michal Hocko [this message]
2016-02-23 22:33 ` David Rientjes
2016-02-24 10:05 ` Michal Hocko
2016-02-24 21:36 ` David Rientjes
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=20160223123457.GC14178@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrea@kernel.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=oleg@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
/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