Re: [PATCH] mm,oom: Do not unfreeze OOM victim thread.

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Michal Hocko wrote:
> On Thu 29-03-18 23:36:58, Tetsuo Handa wrote:
> > Currently, mark_oom_victim() calls __thaw_task() on the OOM victim
> > threads and freezing_slow_path() unfreezes the OOM victim thread.
> > But I think this exceptional behavior makes little sense nowadays.
> 
> Well, I would like to see this happen because it would allow more
> changes on top. E.g. get rid of TIF_MEMDIE finally.

I'm planning to change mark_oom_victim(tsk) to set TIF_MEMDIE only if
tsk == current. That is, "do not set TIF_MEMDIE on remote thread", for
setting TIF_MEMDIE on a thread which might not be doing memory allocation
is not helpful. Setting TIF_MEMDIE on current thread via
task_will_free_mem(current) in out_of_memory() path is always helpful
because current thread is exactly doing memory allocation.

>                                                     But I am not really
> sure we are there yet. OOM reaper is useful tool but it still cannot
> help in some cases (shared memory, a lot of metadata allocated on behalf
> of the process etc...).

I consider the OOM reaper as a useful tool for give up waiting for the OOM
victims after 1 second. Reclaiming memory is optional.

>                         Considering that the freezing can be an
> unprivileged operation (think cgroup freezer) then I am worried that
> one container can cause the global oom killer and hide oom victims to
> the fridge and spill over to other containers.

The OOM reaper will give up after 1 second. What is wrong with keeping
TIF_MEMDIE threads frozen? How does that differ from TIF_MEMDIE threads
being stuck at unkillable waits (e.g. i_mmap_lock_write()).

My understanding is that frozen threads are not holding locks. In this
aspect, frozen TIF_MEMDIE threads are less painful than TIF_MEMDIE threads
being stuck at unkillable waits.

>                                                Maybe I am overly
> paranoid and this scenario is not even all that interesting but I would
> like to hear a better justification which explains all these cases
> rather than "we have oom reaper so we are good to go" rationale.

I'm trying to simplify situations where oom_killer_disable() is called.
You are worrying about situations where oom_killer_disable() is not
called, aren't you?