On Mon 21-08-17 21:57:44, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > Sigh... Let me repeat for the last time (this whole thread is largely a > > waste of time to be honest). Find a _robust_ solution rather than > > fiddling with try-once-more kind of hacks. E.g. do an allocation attempt > > _before_ we do any disruptive action (aka kill a victim). This would > > help other cases when we race with an exiting tasks or somebody managed > > to free memory while we were selecting an oom victim which can take > > quite some time. > > I did not get your answer to my question: > > You don't want to call get_page_from_freelist() from out_of_memory(), do you? > > Since David Rientjes wrote "how sloppy this would be because it's blurring > the line between oom killer and page allocator." and you responded as > "Yes the layer violation is definitely not nice." at > http://lkml.kernel.org/r/20160129152307.GF32174@xxxxxxxxxxxxxx , > I assumed that you don't want to call get_page_from_freelist() from out_of_memory(). Yes that would be a layering violation and I do not like that very much. And that is why I keep repeating that this is something to handle only _if_ the problem is real and happens with _sensible_ workloads so often that we really have to care. If this happens only under oom stress testing then I would be tempted to not care all that much. Please try to understand that OOM killer will never be perfect and adding more kludges and hacks make it more fragile so each additional heuristic should be considered carefully. -- 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>
