Michal Hocko wrote: > > Does "that comment" refer to > > > > Elaborating the comment: the reason for the high wmark is to reduce > > the likelihood of livelocks and be sure to invoke the OOM killer, if > > we're still under pressure and reclaim just failed. The high wmark is > > used to be sure the failure of reclaim isn't going to be ignored. If > > using the min wmark like you propose there's risk of livelock or > > anyway of delayed OOM killer invocation. > > > > part? Then, I know it is not about gfp flags. > > > > But how can OOM livelock happen when the last second allocation does not > > wait for memory reclaim (because __GFP_DIRECT_RECLAIM is masked) ? > > The last second allocation shall return immediately, and we will call > > out_of_memory() if the last second allocation failed. > > I think Andrea just wanted to say that we do want to invoke OOM killer > and resolve the memory pressure rather than keep looping in the > reclaim/oom path just because there are few pages allocated and freed in > the meantime. I see. Then, that motivation no longer applies to current code, except > > [...] > > > I am not sure such a scenario matters all that much because it assumes > > > that the oom victim doesn't really free much memory [1] (basically less than > > > HIGH-MIN). Most OOM situation simply have a memory hog consuming > > > significant amount of memory. > > > > The OOM killer does not always kill a memory hog consuming significant amount > > of memory. The OOM killer kills a process with highest OOM score (and instead > > one of its children if any). I don't think that assuming an OOM victim will free > > memory enough to succeed ALLOC_WMARK_HIGH is appropriate. > > OK, so let's agree to disagree. I claim that we shouldn't care all that > much. If any of the current heuristics turns out to lead to killing too > many tasks then we should simply remove it rather than keep bloating an > already complex code with more and more kluges. using ALLOC_WMARK_HIGH might cause more OOM-killing than ALLOC_WMARK_MIN. Thanks for clarification. -- 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>
