From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, oleg@redhat.com, rientjes@google.com,
vdavydov@parallels.com, mhocko@suse.com
Subject: Re: [RFC PATCH 1/6] oom: keep mm of the killed task available
Date: Sun, 3 Jul 2016 11:45:34 +0900 [thread overview]
Message-ID: <201607031145.HIF90125.LMHQVFJOtOSOFF@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <1467365190-24640-2-git-send-email-mhocko@kernel.org>
Michal Hocko wrote:
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 7d0a275df822..4ea4a649822d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -286,16 +286,17 @@ enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
> * Don't allow any other task to have access to the reserves unless
> * the task has MMF_OOM_REAPED because chances that it would release
> * any memory is quite low.
> + * MMF_OOM_NOT_REAPABLE means that the oom_reaper backed off last time
> + * so let it try again.
> */
> if (!is_sysrq_oom(oc) && atomic_read(&task->signal->oom_victims)) {
> - struct task_struct *p = find_lock_task_mm(task);
> + struct mm_struct *mm = task->signal->oom_mm;
> enum oom_scan_t ret = OOM_SCAN_ABORT;
>
> - if (p) {
> - if (test_bit(MMF_OOM_REAPED, &p->mm->flags))
> - ret = OOM_SCAN_CONTINUE;
> - task_unlock(p);
> - }
> + if (test_bit(MMF_OOM_REAPED, &mm->flags))
> + ret = OOM_SCAN_CONTINUE;
> + else if (test_bit(MMF_OOM_NOT_REAPABLE, &mm->flags))
> + ret = OOM_SCAN_SELECT;
I don't think this is useful.
MMF_OOM_NOT_REAPABLE is set when mm->mmap_sem could not be held for read
by the OOM reaper thread. That occurs when someone is blocked at unkillable
wait with that mm->mmap_sem held for write. Unless the reason that someone
is blocked is lack of CPU time, the reason is likely that that someone is
blocked due to waiting for somebody else's memory allocation. Then, it
won't succeed that retrying OOM reaping MMF_OOM_NOT_REAPABLE mm as soon as
oom_scan_process_thread() finds it. At least, retrying OOM reaping
MMF_OOM_NOT_REAPABLE mm should be attempted after that someone is no longer
blocked due to waiting for somebody else's memory allocation (e.g. retry
only when oom_scan_process_thread() is sure that the OOM reaper thread can
hold mm->mmap_sem for read).
But I don't think with need to dance with task->signal->oom_mm.
See my series which removes task->signal->oom_victims and OOM_SCAN_ABORT case.
>
> return ret;
> }
--
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-07-03 2:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 9:26 [RFC PATCH 0/6] fortify oom killer even more Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 1/6] oom: keep mm of the killed task available Michal Hocko
2016-07-03 2:45 ` Tetsuo Handa [this message]
2016-07-07 8:24 ` Michal Hocko
2016-07-07 11:48 ` Tetsuo Handa
2016-07-07 13:32 ` Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 2/6] oom, suspend: fix oom_killer_disable vs. pm suspend properly Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 3/6] exit, oom: postpone exit_oom_victim to later Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 4/6] oom, oom_reaper: consider mmget_not_zero as a failure Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 5/6] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost Michal Hocko
2016-07-03 13:47 ` Oleg Nesterov
2016-07-03 14:09 ` Michael S. Tsirkin
2016-07-03 15:18 ` Oleg Nesterov
2016-07-03 15:30 ` Michael S. Tsirkin
2016-07-03 16:47 ` Oleg Nesterov
2016-07-03 21:17 ` Michael S. Tsirkin
2016-07-07 8:28 ` Michal Hocko
2016-07-07 15:38 ` Michael S. Tsirkin
2016-07-08 12:29 ` Oleg Nesterov
2016-07-11 14:14 ` Michal Hocko
2016-07-12 14:33 ` Oleg Nesterov
2016-07-07 8:42 ` Michal Hocko
2016-07-07 16:46 ` Oleg Nesterov
2016-07-07 8:39 ` Michal Hocko
2016-07-22 11:09 ` Michal Hocko
2016-07-01 9:26 ` [RFC PATCH 6/6] oom, oom_reaper: allow to reap mm shared by the kthreads 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=201607031145.HIF90125.LMHQVFJOtOSOFF@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=oleg@redhat.com \
--cc=rientjes@google.com \
--cc=vdavydov@parallels.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