On Wed 30-11-16 14:16:13, Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote:
[...]
> > But... Unless I am missing something this effectively means that we do
> > not exercise high order atomic reserves. Shouldn't we fallback to
> > the locked __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC) for
> > order > 0 && ALLOC_HARDER ? Or is this just hidden in some other code
> > path which I am not seeing?
> >
>
> Good spot, would this be acceptable to you?
It's not a queen of beauty but it works. A more elegant solution would
require more surgery I guess which is probably not worth it at this
stage.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 91dc68c2a717..94808f565f74 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2609,9 +2609,18 @@ struct page *buffered_rmqueue(struct zone
> *preferred_zone,
> int nr_pages = rmqueue_bulk(zone, order,
> pcp->batch, list,
> migratetype, cold);
> - pcp->count += (nr_pages << order);
> - if (unlikely(list_empty(list)))
> + if (unlikely(list_empty(list))) {
> + /*
> + * Retry high-order atomic allocs
> + * from the buddy list which may
> + * use MIGRATE_HIGHATOMIC.
> + */
> + if (order && (alloc_flags &
> ALLOC_HARDER))
> + goto try_buddylist;
> +
> goto failed;
> + }
> + pcp->count += (nr_pages << order);
> }
>
> if (cold)
> @@ -2624,6 +2633,7 @@ struct page *buffered_rmqueue(struct zone
> *preferred_zone,
>
> } while (check_new_pcp(page));
> } else {
> +try_buddylist:
> /*
> * We most definitely don't want callers attempting to
> * allocate greater than order-1 page units with __GFP_NOFAIL.
> --
> Mel Gorman
> SUSE Labs
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"d...@kvack.org";> em...@kvack.org </a>
--
Michal Hocko
SUSE Labs
