On Thu 03-03-16 01:54:43, Hugh Dickins wrote: > On Tue, 1 Mar 2016, Michal Hocko wrote: [...] > > So I have tried the following: > > diff --git a/mm/compaction.c b/mm/compaction.c > > index 4d99e1f5055c..7364e48cf69a 100644 > > --- a/mm/compaction.c > > +++ b/mm/compaction.c > > @@ -1276,6 +1276,9 @@ static unsigned long __compaction_suitable(struct zone *zone, int order, > > alloc_flags)) > > return COMPACT_PARTIAL; > > > > + if (order <= PAGE_ALLOC_COSTLY_ORDER) > > + return COMPACT_CONTINUE; > > + > > I gave that a try just now, but it didn't help me: OOMed much sooner, > after doing half as much work. I do not have an explanation why it would cause oom sooner but this turned out to be incomplete. There is another wmaark check deeper in the compaction path. Could you try the one from http://lkml.kernel.org/r/20160302130022.GG26686@xxxxxxxxxxxxxx I will try to find a machine with more CPUs and try to reproduce this in the mean time. I will also have a look at the data you have collected. -- 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>