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

From: Dev Jain

Date: Thu Jul 09 2026 - 05:06:51 EST




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!

One other function to batch is page_vma_mkclean_one, but we do not already
have the folio there, so have to be careful.


> I think either is fine, but wanted to check the preference.
>
> Thanks,
> Shivank