> On Aug 6, 2024, at 1:05 AM, Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> wrote:
>
>
>
> On 2024/8/6 0:31, Aruna Ramakrishna wrote:
>> Convert alloc_pages_noprof() to use folio_alloc_mpol_noprof() so that
>> alloc_pages_mpol(_noprof)() can be removed in a future commit.
>> Signed-off-by: Aruna Ramakrishna <aruna.ramakrishna@xxxxxxxxxx>
>> ---
>> mm/mempolicy.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index b3b5f376471f..2d367ef15d0f 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -2332,6 +2332,7 @@ EXPORT_SYMBOL(vma_alloc_folio_noprof);
>> struct page *alloc_pages_noprof(gfp_t gfp, unsigned int order)
>> {
>> struct mempolicy *pol = &default_policy;
>> + struct folio *folio;
>> /*
>> * No reference counting needed for current->mempolicy
>> @@ -2340,8 +2341,10 @@ struct page *alloc_pages_noprof(gfp_t gfp, unsigned int order)
>> if (!in_interrupt() && !(gfp & __GFP_THISNODE))
>> pol = get_task_policy(current);
>> - return alloc_pages_mpol_noprof(gfp, order, pol, NO_INTERLEAVE_INDEX,
>> - numa_node_id());
>> + folio = folio_alloc_mpol_noprof(gfp, order, pol, NO_INTERLEAVE_INDEX,
>> + numa_node_id());
>
> We have __GFP_COMP in folio_alloc_mpol_noprof and set large_rmappable
> for large folio, not sure that there is some issue for alloc_pages()
> callers.
>
Hi Kefeng,
You’re right, this will force all callers of alloc_pages() to use __GFP_COMP which,
at this point, seems risky to do. I was trying to find a way to separate out the compound
page users from the non-, but it makes things too complicated. I do not think it is possible
to convert alloc_pages_noprof() to folios at this point, without addressing that first.
Thank you for catching that.
Thanks,
Aruna
