Michal Hocko wrote: > On Tue 05-12-17 22:17:27, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > > I do understand the upsides you're advocating for - although you > > > > haven't quantified them. They're just not worth the downsides. > > > > > > OK, fair enough. Let's drop the patch then. There is no _strong_ > > > justification for it and what I've seen as "nice to have" is indeed > > > really hard to quantify and not really worth merging without a full > > > consensus. > > > > Dropping "mm,oom: move last second allocation to inside the OOM killer" > > means dropping "mm,oom: remove oom_lock serialization from the OOM reaper" > > together, right? > > No, I believe that we can drop the lock even without this patch. This > will need more investigation though. We cannot drop the lock without this patch. > > > The latter patch helped mitigating > > schedule_timeout_killable(1) lockup problem though... > > > > Also, what is the alternative for "mm,oom: use ALLOC_OOM for OOM victim's > > last second allocation" ? I proposed "mm, oom: task_will_free_mem(current) > > should ignore MMF_OOM_SKIP for once." and rejected by you. I also proposed > > "mm,oom: Set ->signal->oom_mm to all thread groups sharing the victim's mm." > > and rejected by you. > > Yes, and so far I am not really sure we have to care all that much. I > haven't seen any real world workload actually hitting this condition. > Somebody will observe what Manish Jaggi observed. OOM with mlock()ed and/or MAP_SHARED is irrelevant. There is always possibility that the OOM reaper fails to reclaim memory due to mmap_sem contention (and results in extra OOM kills). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
