Re: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one

[Dev Jain <dev.jain@arm.com>]

On 09/07/26 2:50 pm, Garg, Shivank wrote:
> 
> 
> On 7/9/2026 2:28 PM, Dev Jain wrote:
>>
>>
>> On 09/07/26 12:46 pm, Garg, Shivank wrote:
>>>
>>>
>>> On 5/26/2026 12:06 PM, Dev Jain wrote:
>>>> Simplify try_to_unmap_one by separating out the hugetlb parts into
>>>> try_to_unmap_hugetlb_one.
>>>
>>> [snip]
>>>
>>>> @@ -2393,7 +2431,8 @@ static int folio_not_mapped(struct folio *folio)
>>>>  void try_to_unmap(struct folio *folio, enum ttu_flags flags)
>>>>  {
>>>>  	struct rmap_walk_control rwc = {
>>>> -		.rmap_one = try_to_unmap_one,
>>>> +		.rmap_one = folio_test_hugetlb(folio) ?
>>>> +				try_to_unmap_hugetlb_one : try_to_unmap_one,
>>>>  		.arg = (void *)flags,
>>>>  		.done = folio_not_mapped,
>>>>  		.anon_lock = folio_lock_anon_vma_read,
>>>
>>> Now that try_to_unmap_hugetlb_one() is split out, should we wrap it in
>>> #ifdef CONFIG_HUGETLB_PAGE and a stub function for !HUGETLB case?
>>
>> I'd rather not, if everything builds correctly?
>>
>>
>>>
>>> I'm working on similar change for try_to_migrate() and had this thought.
>>
>> Wait, are you doing the batching work for try_to_migrate()? I had
>> that as an obvious follow up to this series so if you are already on it
>> then great!
>>
> 
> Yes,
> I'm seeing significant throughput boost when combining it with my batch copy offloading series [1]
> Once batch copying removes the copy bottleneck, the rmap walk becomes the dominant cost for PTE-mapped
> large folios.
> 
> My experiment with move_pages() on two-socket EPYC Zen 3 to move 1GB anon memory from node 0 -> node 1:
> 
>   folio   vanilla     DMA (dcbm, 16 chan)
>   -----   --------    -------------------
>   2MB     10.7 GB/s   64.3  (6.0x) -> no change for PMD mapped
>   1MB      7.0 GB/s   14.3  (2.0x) copy offlaod
>                       39.0  (5.6x) + rmap batching
>   256KB    6.7 GB/s   13.0  (1.9x) copy offload
>                       32.3  (4.8x) + rmap batching

Ooh very nice, numbers are awesome!


> 
> [1] https://lore.kernel.org/linux-mm/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com
>  
>> One other function to batch is page_vma_mkclean_one, but we do not already
>> have the folio there, so have to be careful.
> 
> 
> Thanks,
> Shivank
>