On Sat 01-09-18 20:48:57, Tetsuo Handa wrote: > On 2018/08/07 5:51, Michal Hocko wrote: > >> At the risk of continually repeating the same statement, the oom reaper > >> cannot provide the direct feedback for all possible memory freeing. > >> Waking up periodically and finding mm->mmap_sem contended is one problem, > >> but the other problem that I've already shown is the unnecessary oom > >> killing of additional processes while a thread has already reached > >> exit_mmap(). The oom reaper cannot free page tables which is problematic > >> for malloc implementations such as tcmalloc that do not release virtual > >> memory. > > > > But once we know that the exit path is past the point of blocking we can > > have MMF_OOM_SKIP handover from the oom_reaper to the exit path. So the > > oom_reaper doesn't hide the current victim too early and we can safely > > wait for the exit path to reclaim the rest. So there is a feedback > > channel. I would even do not mind to poll for that state few times - > > similar to polling for the mmap_sem. But it would still be some feedback > > rather than a certain amount of time has passed since the last check. > > Michal, will you show us how we can handover as an actual patch? I'm not > happy with postponing current situation with just your wish to handover. I am sorry but I am bussy with other higher priority issues. I believe I have outlined the scheme that might work (see above). All it takes is to look into that closer a play with it. I haven't seen bug reports except for David's very vaguely argued report. I have asked about details several times but haven't received any. So I didn't really give it a top priority and consider it as a corner case which is nice to solve rather than absolutely have to do it right away because many users would put spell on us because their workloads are eaten by that evil OOM killer. If I've misinterpreted the priority then I can certainly reconsider and reprioritize or somebody else might have a look into it. -- Michal Hocko SUSE Labs
