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. 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...). 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. 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. -- Michal Hocko SUSE Labs
