On Fri 23-09-16 00:22:57, Tetsuo Handa wrote: [...] > As a first step, I do want to eliminate possibility of silent OOM livelock. Absolutely no! Unless you have a clear evidence that the oom livelock is real and easily triggerable from the userspace. Pre-mature OOM killer is imho much worse problem than a theoretical GFP_NOFS livelock. So NAK to this patch from me. We just have too many GFP_NOFS users currently and the risk of pre-mature OOM is just too high wrt to gain this will give us. I really think we need a real solution rather than just blindly disable this code and hope everything will happen to work. As I've said in the past I am not fond of this heuristic either but we do not have anything better now. I am all for warning when an allocation stalls for too long to identify potential problems. Will post a patch later today. > If this patch causes !__GFP_FS memory allocation requests to invoke the > OOM killer trivially, at least we will be able to emit warning messages > periodically as long as we are telling the lie instead of invoking the > OOM killer. Without knowing which caller is falling into OOM livelock, > we will remain too cowardly to determine when we can stop telling the > lie and we will bother administrators with silent OOM livelock. > > Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxx> > Cc: David Rientjes <rientjes@xxxxxxxxxx> > Cc: Johannes Weiner <hannes@xxxxxxxxxxx> > --- > mm/oom_kill.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index f284e92..7893c5c 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -1005,15 +1005,6 @@ bool out_of_memory(struct oom_control *oc) > } > > /* > - * The OOM killer does not compensate for IO-less reclaim. > - * pagefault_out_of_memory lost its gfp context so we have to > - * make sure exclude 0 mask - all other users should have at least > - * ___GFP_DIRECT_RECLAIM to get here. > - */ > - if (oc->gfp_mask && !(oc->gfp_mask & (__GFP_FS|__GFP_NOFAIL))) > - return true; > - > - /* > * Check if there were limitations on the allocation (only relevant for > * NUMA and memcg) that may require different handling. > */ > -- > 1.8.3.1 -- 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>