On Thu, 3 Mar 2016, Michal Hocko wrote: > 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 think I exaggerated: sooner, but not _much_ sooner; and I cannot see now what I based that estimate of "half as much work" on. > > 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've now added that in: it corrects the "sooner", but does not make any difference to the fact of OOMing for me. Hugh > > 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>