On Fri 08-12-17 19:58:11, Tetsuo Handa wrote: [...] > Therefore, I'm stuck between Michal and Johannes. And I updated "mm,oom: use > ALLOC_OOM for OOM victim's last second allocation" not to depend on "mm,oom: > move last second allocation to inside the OOM killer". No, you seem to be stuck elsewhere. You keep ignoring that the OOM killer is a best effort heuristic to free up some memory. And as any other heuristic it has to balance cons and pros. One of the biggest argument in those decision is how _serious_ the problem is another tweak worth all the possible downfalls? You keep repeating Manish report which is an _artificial_ OOM scenario. It is true that we can do better in that case but the real solution looks differently - we should make mlocked memory reapable. Now that is not a trivial thing to do and I still have that on my todo list. You are actively avoiding the real solution by providing tweaks (try one more time) here and there. I really hate that approach. This will make the behavior time dependant as Johannes pointed out. I was OK with your "move the last allocation attempt" because it conceptually makes some sense at least. Johannes had arguments against and I do respect them because I do agree it is not a general and _measurable_ win. And this is how the consensus based develoment works. We are not pushing for questionable solutions unless there is an absolute urge for that because the issue is serious and many users suffer from it yet there is no real solution in sight. See the difference? That being said, I will keep refusing other such tweaks unless you have a sound usecase behind. If you really _want_ to help out here then you can focus on the reaping of the mlock memory. Thanks -- Michal Hocko SUSE Labs -- 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>
