On Tue 11-07-17 17:45:41, Johannes Weiner wrote:
[...]
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index a56c3989f773..efd3f48c667c 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -52,18 +52,24 @@ void * __meminit vmemmap_alloc_block(unsigned long size, 
> int node)
>  {
>       /* If the main allocator is up use that, fallback to bootmem. */
>       if (slab_is_available()) {
> +             unsigned int order;
> +             static int warned;
>               struct page *page;
> +             gfp_t gfp_mask;
>  
> +             order = get_order(size);
> +             gfp_mask = GFP_KERNEL|__GFP_ZERO|__GFP_REPEAT|__GFP_NOWARN;

why not do
                gfp_mask = GFP_KERNEL|__GFP_ZERO|__GFP_REPEAT;
                if (warned)
                        gfp_mask |= __GFP_NOWARN;

and get the actual allocation warning from the allocation context. Then
we can keep the warning vmemmap_populate_hugepages because that would be
more descriptive that what is going on.

Btw. __GFP_REPEAT has been replaced by __GFP_RETRY_MAYFAIL in mmotm
tree.

>               if (node_state(node, N_HIGH_MEMORY))
> -                     page = alloc_pages_node(
> -                             node, GFP_KERNEL | __GFP_ZERO | __GFP_REPEAT,
> -                             get_order(size));
> +                     page = alloc_pages_node(node, gfp_mask, size);
>               else
> -                     page = alloc_pages(
> -                             GFP_KERNEL | __GFP_ZERO | __GFP_REPEAT,
> -                             get_order(size));
> +                     page = alloc_pages(gfp_mask, size);
>               if (page)
>                       return page_address(page);
> +             if (!warned) {
> +                     warn_alloc(gfp_mask, NULL,
> +                                "vmemmap alloc failure: order:%u", order);
> +                     warned = 1;
> +             }
>               return NULL;
>       } else
>               return __earlyonly_bootmem_alloc(node, size, size,

-- 
Michal Hocko
SUSE Labs

Reply via email to