All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Aaron Tomlin <atomlin@redhat.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz,
	penguin-kernel@i-love.sakura.ne.jp, llong@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/oom_kill: show oom eligibility when displaying the current memory state of all tasks
Date: Mon, 14 Jun 2021 08:44:19 +0200	[thread overview]
Message-ID: <YMb6w/bGdhJvOy6j@dhcp22.suse.cz> (raw)
In-Reply-To: <20210612204634.1102472-1-atomlin@redhat.com>

On Sat 12-06-21 21:46:34, Aaron Tomlin wrote:
> Changes since v2:
>  - Use single character (e.g. 'R' for MMF_OOM_SKIP) as suggested
>    by Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
>  - Add new header to oom_dump_tasks documentation
> 
> 
> At the present time, when showing potential OOM victims, we do not
> exclude tasks which already have MMF_OOM_SKIP set; it is possible that
> the last OOM killable victim was already OOM killed, yet the OOM
> reaper failed to reclaim memory and set MMF_OOM_SKIP.
> This can be confusing/or perhaps even misleading, to the reader of the
> OOM report. Now, we already unconditionally display a task's
> oom_score_adj_min value that can be set to OOM_SCORE_ADJ_MIN which is
> indicative of an "unkillable" task i.e. is not eligible.

Well, I have to say that I have a bit hard time understand the problem
statement here. First of all you are very likely basing your observation
on an old kernel which is missing a fix which should make the situation
impossible IIRC. You should be focusing on a justification why the new
information is helpful for the current tree.

Historically, all tasks eligible for the oom killing have been
printed. That includes also tasks which are excluded later in the
selection. E.g. OOMS_SCORE_ADJ_MIN which can be tricky indeed. IIRC the
primary reason was to have a sufficient amount of information to
evaluate whether the system is configured properly (e.g.
OOMS_SCORE_ADJ_MIN is not used too extensively). More excluded
criterion have been added due to implementation details
(e.g.MMF_OOM_SKIP or mm shared with otherwise ineligible task.

You are correctly pointing out that those internal states are not
exposed but you should focus on explanation why that gap really stands
in the way for the current upstream. Who is going to consume that
information and for what purpose?

> This patch provides a clear indication with regard to the OOM
> eligibility of each displayed task.

This should provide an example of the output with a clarification of the
meaning.

[...]
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2021-06-14  6:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-12 20:46 [PATCH v2] mm/oom_kill: show oom eligibility when displaying the current memory state of all tasks Aaron Tomlin
2021-06-13 23:47 ` David Rientjes
2021-06-15 12:02   ` Aaron Tomlin
2021-06-14  6:44 ` Michal Hocko [this message]
2021-06-15 11:51   ` Aaron Tomlin
2021-06-15 12:42     ` Michal Hocko
2021-06-16 20:18       ` Aaron Tomlin

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=YMb6w/bGdhJvOy6j@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llong@redhat.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=vbabka@suse.cz \
    /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.