Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1373311
| From | Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper |
| Date | 2016-04-07 14:00 +0200 |
| Message-ID | <rlgLo-3f5-9@gated-at.bofh.it> (permalink) |
| References | <rkWtk-56i-7@gated-at.bofh.it> <rkWtk-56i-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Michal Hocko wrote: > The first obvious one is when the oom victim clears its mm and gets > stuck later on. oom_reaper would back of on find_lock_task_mm returning > NULL. We can safely try to clear TIF_MEMDIE in this case because such a > task would be ignored by the oom killer anyway. The flag would be > cleared by that time already most of the time anyway. I didn't understand what this wants to tell. The OOM victim will clear TIF_MEMDIE as soon as it sets current->mm = NULL. Even if the oom victim clears its mm and gets stuck later on (e.g. at exit_task_work()), TIF_MEMDIE was already cleared by that moment by the OOM victim. > > The less obvious one is when the oom reaper fails due to mmap_sem > contention. Even if we clear TIF_MEMDIE for this task then it is not > very likely that we would select another task too easily because > we haven't reaped the last victim and so it would be still the #1 > candidate. There is a rare race condition possible when the current > victim terminates before the next select_bad_process but considering > that oom_reap_task had retried several times before giving up then > this sounds like a borderline thing. Is it helpful? Allowing the OOM killer to select the same thread again simply makes the kernel log buffer flooded with the OOM kill messages. I think we should not allow the OOM killer to select the same thread again by e.g. doing tsk->signal->oom_score_adj = OOM_SCORE_ADJ_MIN regardless of whether reaping that thread's memory succeeded or not.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/3] oom reaper follow ups v1 Michal Hocko <mhocko@kernel.org> - 2016-04-06 16:20 +0200
[PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper Michal Hocko <mhocko@kernel.org> - 2016-04-06 16:20 +0200
Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-04-07 14:00 +0200
Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper Michal Hocko <mhocko@kernel.org> - 2016-04-08 13:40 +0200
Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper Michal Hocko <mhocko@kernel.org> - 2016-04-08 15:10 +0200
[PATCH 1/3] mm, oom: move GFP_NOFS check to out_of_memory Michal Hocko <mhocko@kernel.org> - 2016-04-06 16:20 +0200
csiph-web