Re: [PATCH] mm, oom: protect !costly allocations some more

[Michal Hocko]

On Tue 08-03-16 10:24:56, Vlastimil Babka wrote:
[...]
> > @@ -2819,28 +2819,22 @@ static struct page *
> >  __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
> >  		int alloc_flags, const struct alloc_context *ac,
> >  		enum migrate_mode mode, int *contended_compaction,
> > -		bool *deferred_compaction)
> > +		unsigned long *compact_result)
> >  {
> > -	unsigned long compact_result;
> >  	struct page *page;
> >  
> > -	if (!order)
> > +	if (!order) {
> > +		*compact_result = COMPACT_NONE;
> >  		return NULL;
> > +	}
> >  
> >  	current->flags |= PF_MEMALLOC;
> > -	compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
> > +	*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
> >  						mode, contended_compaction);
> >  	current->flags &= ~PF_MEMALLOC;
> >  
> > -	switch (compact_result) {
> > -	case COMPACT_DEFERRED:
> > -		*deferred_compaction = true;
> > -		/* fall-through */
> > -	case COMPACT_SKIPPED:
> > +	if (*compact_result <= COMPACT_SKIPPED)
> 
> COMPACT_NONE is -1 and compact_result is unsigned long, so this won't
> work as expected.

Well, COMPACT_NONE is documented as /* compaction disabled */ so we
should never get it from try_to_compact_pages.

[...]
> > @@ -3294,6 +3289,18 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> >  				 did_some_progress > 0, no_progress_loops))
> >  		goto retry;
> >  
> > +	/*
> > +	 * !costly allocations are really important and we have to make sure
> > +	 * the compaction wasn't deferred or didn't bail out early due to locks
> > +	 * contention before we go OOM.
> > +	 */
> > +	if (order && order <= PAGE_ALLOC_COSTLY_ORDER) {
> > +		if (compact_result <= COMPACT_CONTINUE)
> 
> Same here.
> I was going to say that this didn't have effect on Sergey's test, but
> turns out it did :)

This should work as expected because compact_result is unsigned long
and so this is the unsigned arithmetic. I can make
#define COMPACT_NONE            -1UL

to make the intention more obvious if you prefer, though.

Thanks for the review.
-- 
Michal Hocko
SUSE Labs