Received-SPF: pass (google.com: domain of linux-kernel+bounces-156433-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <5b663fcc-cace-4091-aa56-e88b00ec1d1c@linux.alibaba.com>
Date: Wed, 24 Apr 2024 14:55:59 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 2/5] mm: shmem: add an 'order' parameter for
 shmem_alloc_hugefolio()
To: Kefeng Wang <wangkefeng.wang@huawei.com>, akpm@linux-foundation.org,
 hughd@google.com
Cc: willy@infradead.org, david@redhat.com, 21cnbao@gmail.com,
 ryan.roberts@arm.com, ying.huang@intel.com, shy828301@gmail.com,
 ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org
References: <cover.1713755580.git.baolin.wang@linux.alibaba.com>
 <2014bf7370d78bc1f5600731af5bf8f569e5868b.1713755580.git.baolin.wang@linux.alibaba.com>
 <c51d8d04-e108-4a0c-9f0b-7c47b619a76c@huawei.com>
From: Baolin Wang <baolin.wang@linux.alibaba.com>
In-Reply-To: <c51d8d04-e108-4a0c-9f0b-7c47b619a76c@huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 2024/4/24 14:28, Kefeng Wang wrote:
> 
> 
> On 2024/4/22 15:02, Baolin Wang wrote:
>> Add a new parameter to specify the huge page order for 
>> shmem_alloc_hugefolio(),
>> as a preparation to supoort mTHP.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> ---
>>   mm/shmem.c | 11 ++++++-----
>>   1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index fa2a0ed97507..893c88efc45f 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -1604,14 +1604,14 @@ static gfp_t limit_gfp_mask(gfp_t huge_gfp, 
>> gfp_t limit_gfp)
>>   }
>>   static struct folio *shmem_alloc_hugefolio(gfp_t gfp,
>> -        struct shmem_inode_info *info, pgoff_t index)
>> +        struct shmem_inode_info *info, pgoff_t index, int order)
>>   {
>>       struct mempolicy *mpol;
>>       pgoff_t ilx;
>>       struct page *page;
>> -    mpol = shmem_get_pgoff_policy(info, index, HPAGE_PMD_ORDER, &ilx);
>> -    page = alloc_pages_mpol(gfp, HPAGE_PMD_ORDER, mpol, ilx, 
>> numa_node_id());
>> +    mpol = shmem_get_pgoff_policy(info, index, order, &ilx);
>> +    page = alloc_pages_mpol(gfp, order, mpol, ilx, numa_node_id());
>>       mpol_cond_put(mpol);
>>       return page_rmappable_folio(page);
>> @@ -1639,13 +1639,14 @@ static struct folio 
>> *shmem_alloc_and_add_folio(gfp_t gfp,
>>       struct shmem_inode_info *info = SHMEM_I(inode);
>>       struct folio *folio;
>>       long pages;
>> -    int error;
>> +    int error, order;
>>       if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
>>           huge = false;
>>       if (huge) {
>>           pages = HPAGE_PMD_NR;
>> +        order = HPAGE_PMD_ORDER;
>>           index = round_down(index, HPAGE_PMD_NR);
>>           /*
>> @@ -1660,7 +1661,7 @@ static struct folio 
>> *shmem_alloc_and_add_folio(gfp_t gfp,
>>                   index + HPAGE_PMD_NR - 1, XA_PRESENT))
>>               return ERR_PTR(-E2BIG);
>> -        folio = shmem_alloc_hugefolio(gfp, info, index);
>> +        folio = shmem_alloc_hugefolio(gfp, info, index, order);
> 
> Avoid order variable, we can directly use HPAGE_PMD_NR here.

Yes, sure. Thanks.