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

["Garg, Shivank" <shivankg@amd.com>]

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

[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