On Sat 07-07-18 10:12:57, Tetsuo Handa wrote: [...] > On 2018/07/06 14:56, Michal Hocko wrote: > >>> Yes, there is no need to reclaim all pages. OOM is after freeing _some_ > >>> memory after all. But that means further complications down the unmap > >>> path. I do not really see any reason for that. > >> > >> "I do not see reason for that" cannot become a reason direct OOM reaping has to > >> reclaim all pages at once. > > > > We are not going to polute deep mm guts for unlikely events like oom. > > And since Michal is refusing to make changes for having the balance between > "direct reclaim by threads waiting for oom_lock" and "indirect reclaim by > a thread holding oom_lock", we will keep increasing possibility of hitting > "0 pages per minute". Therefore, > > > If you are afraid of > > regression and do not want to have your name on the patch then fine. I > > will post the patch myself and also handle any fallouts. > > PLEASE PLEASE PLEASE DO SO IMMEDIATELY!!! Curiously enough I've done so back in May [1] just to hear some really weird arguments (e.g. that I am not solving an unrelated problem in the memcg oom killer etc) and other changes of yours that were (again) intermixing different things together. So then I've ended up with [2]. I will resubmit that patch. But please note how your insisting has only delayed the whole thing. If I were you I would really think twice before blaming someone from malicious intentions or even refusing good changes from being merged. [1] http://lkml.kernel.org/r/20180528124313.GC27180@xxxxxxxxxxxxxx [2] http://lkml.kernel.org/r/20180601080443.GX15278@xxxxxxxxxxxxxx -- Michal Hocko SUSE Labs
