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.
