On Tue 30-10-18 22:57:37, Tetsuo Handa wrote: > On 2018/10/30 21:10, Michal Hocko wrote: > > I misunderstood your concern. oom_reaper would back off without > > MMF_OOF_SKIP as well. You are right we cannot assume anything about > > close callbacks so MMF_OOM_SKIP has to come before that. I will move it > > behind the pagetable freeing. > > > > And at that point, your patch can at best wait for only __free_pgtables(), Yes, mostly on the grounds that oom victims are mostly sitting on mapped memory and page tables. I can see how last ->close() can release some memory as well but a) we do not consider that memory when selecting a victim and b) it shouldn't be a large memory consumer on its own. > at the cost/risk of complicating exit_mmap() and arch specific code.Also, > you are asking for comments to wrong audiences. It is arch maintainers who > need to precisely understand the OOM behavior / possibility of OOM lockup, > and you must persuade them about restricting/complicating future changes in > their arch code due to your wish to allow handover. Without "up-to-dated > big fat comments to all relevant functions affected by your change" and > "acks from all arch maintainers", I'm sure that people keep making > errors/mistakes/overlooks. Are you talking about arch_exit_mmap or which part of the arch code? > My patch can wait for completion of (not only exit_mmap() but also) __mmput(), > by using simple polling approach. My patch can allow NOMMU kernels to avoid > possibility of OOM lockup by setting MMF_OOM_SKIP at __mmput() (and future > patch will implement timeout based back off for NOMMU kernels), and allows you > to get rid of TIF_MEMDIE (which you recently added to your TODO list) by getting > rid of conditional handling of oom_reserves_allowed() and ALLOC_OOM. OK, let's settle on a simple fact. I would like to discuss _this_ approach here. Bringing up _yours_ all the time is not productive much. You might have noticed that I have posted this for discussion (hence the RGC) and as such I would appreciate staying on the topic. What is the best approach in the end is a matter of discsussion of course. At thise stage it is quite clear we can only agree to disagree which approach is better and discussing the same set of points back and forth is not going to get us anywhere. Therefore we would have to rely on the maintainer to decide. -- Michal Hocko SUSE Labs
