On Thu 16-07-20 14:54:01, Tetsuo Handa wrote: > On 2020/07/16 2:30, David Rientjes wrote: > > But regardless of whether we present previous data to the user in the > > kernel log or not, we've determined that oom killing a process is a > > serious matter and go to any lengths possible to avoid having to do it. > > For us, that means waiting until the "point of no return" to either go > > ahead with oom killing a process or aborting and retrying the charge. > > > > I don't think moving the mem_cgroup_margin() check to out_of_memory() > > right before printing the oom info and killing the process is a very > > invasive patch. Any strong preference against doing it that way? I think > > moving the check as late as possible to save a process from being killed > > when racing with an exiter or killed process (including perhaps current) > > has a pretty clear motivation. > > > > How about ignoring MMF_OOM_SKIP for once? I think this has almost same > effect as moving the mem_cgroup_margin() check to out_of_memory() > right before printing the oom info and killing the process. How would that help with races when a task is exiting while the oom selects a victim? We are not talking about races with the oom_reaper IIUC. Btw. if races with the oom_reaper are a concern then I would much rather delay the wake up than complicate the existing protocol even further. -- Michal Hocko SUSE Labs
