Re: [PATCH] mm/page_alloc: skip THP-sized PCP list when allocating non-CMA THP-sized page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 4, 2024 at 9:15 PM <yangge1116@xxxxxxx> wrote:
>
> From: yangge <yangge1116@xxxxxxx>
>
> Since commit 5d0a661d808f ("mm/page_alloc: use only one PCP list for
> THP-sized allocations") no longer differentiates the migration type
> of pages in THP-sized PCP list, it's possible to get a CMA page from
> the list, in some cases, it's not acceptable, for example, allocating
> a non-CMA page with PF_MEMALLOC_PIN flag returns a CMA page.
>
> The patch forbids allocating non-CMA THP-sized page from THP-sized
> PCP list to avoid the issue above.

Could you please describe the impact on users in the commit log?
Is it possible that some CMA memory might be used by non-movable
allocation requests? If so, will CMA somehow become unable to
migrate, causing cma_alloc() to fail?

>
> Fixes: 5d0a661d808f ("mm/page_alloc: use only one PCP list for THP-sized allocations")
> Signed-off-by: yangge <yangge1116@xxxxxxx>
> ---
>  mm/page_alloc.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 2e22ce5..0bdf471 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2987,10 +2987,20 @@ struct page *rmqueue(struct zone *preferred_zone,
>         WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));
>
>         if (likely(pcp_allowed_order(order))) {
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +               if (!IS_ENABLED(CONFIG_CMA) || alloc_flags & ALLOC_CMA ||
> +                                               order != HPAGE_PMD_ORDER) {
> +                       page = rmqueue_pcplist(preferred_zone, zone, order,
> +                                               migratetype, alloc_flags);
> +                       if (likely(page))
> +                               goto out;
> +               }

This seems not ideal, because non-CMA THP gets no chance to use PCP. But it
still seems better than causing the failure of CMA allocation.

Is there a possible approach to avoiding adding CMA THP into pcp from the first
beginning? Otherwise, we might need a separate PCP for CMA.

> +#else
>                 page = rmqueue_pcplist(preferred_zone, zone, order,
>                                        migratetype, alloc_flags);
>                 if (likely(page))
>                         goto out;
> +#endif
>         }
>
>         page = rmqueue_buddy(preferred_zone, zone, order, alloc_flags,
> --
> 2.7.4

Thanks
Barry





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux