[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201601131952.HAJ18298.OQLtSOFOFFMVJH@I-love.SAKURA.ne.jp>
Date: Wed, 13 Jan 2016 19:52:08 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: rientjes@...gle.com
Cc: mhocko@...nel.org, hannes@...xchg.org, akpm@...ux-foundation.org,
mgorman@...e.de, torvalds@...ux-foundation.org, oleg@...hat.com,
hughd@...gle.com, andrea@...nel.org, riel@...hat.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm,oom: Exclude TIF_MEMDIE processes from candidates.
David Rientjes wrote:
> > @@ -171,7 +195,7 @@ unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
> > if (oom_unkillable_task(p, memcg, nodemask))
> > return 0;
> >
> > - p = find_lock_task_mm(p);
> > + p = find_lock_non_victim_task_mm(p);
> > if (!p)
> > return 0;
> >
>
> I understand how this may make your test case pass, but I simply don't
> understand how this could possibly be the correct thing to do. This would
> cause oom_badness() to return 0 for any process where a thread has
> TIF_MEMDIE set. If the oom killer is called from the page allocator,
> kills a thread, and it is recalled before that thread may exit, then this
> will panic the system if there are no other eligible processes to kill.
>
Why? oom_badness() is called after oom_scan_process_thread() returned OOM_SCAN_OK.
oom_scan_process_thread() returns OOM_SCAN_ABORT if a thread has TIF_MEMDIE set.
If the TIF_MEMDIE thread already exited, find_lock_non_victim_task_mm() acts like
find_lock_task_mm(). Otherwise, oom_scan_process_thread() acts like a blocker.
Powered by blists - more mailing lists