Re: [PATCH v4 2/7] mm/huge_memory: convert "tva_flags" to "enum tva_type"

[Usama Arif <usamaarif642@gmail.com>]

On 14/08/2025 04:07, Yafang Shao wrote:
> On Wed, Aug 13, 2025 at 9:57 PM Usama Arif <usamaarif642@gmail.com> wrote:
>>
>> From: David Hildenbrand <david@redhat.com>
>>
>> When determining which THP orders are eligible for a VMA mapping,
>> we have previously specified tva_flags, however it turns out it is
>> really not necessary to treat these as flags.
>>
>> Rather, we distinguish between distinct modes.
>>
>> The only case where we previously combined flags was with
>> TVA_ENFORCE_SYSFS, but we can avoid this by observing that this
>> is the default, except for MADV_COLLAPSE or an edge cases in
>> collapse_pte_mapped_thp() and hugepage_vma_revalidate(), and
>> adding a mode specifically for this case - TVA_FORCED_COLLAPSE.
>>
>> We have:
>> * smaps handling for showing "THPeligible"
>> * Pagefault handling
>> * khugepaged handling
>> * Forced collapse handling: primarily MADV_COLLAPSE, but also for
>>   an edge case in collapse_pte_mapped_thp()
>>
>> Disregarding the edge cases, we only want to ignore sysfs settings only
>> when we are forcing a collapse through MADV_COLLAPSE, otherwise we
>> want to enforce it, hence this patch does the following flag to enum
>> conversions:
>>
>> * TVA_SMAPS | TVA_ENFORCE_SYSFS -> TVA_SMAPS
>> * TVA_IN_PF | TVA_ENFORCE_SYSFS -> TVA_PAGEFAULT
>> * TVA_ENFORCE_SYSFS             -> TVA_KHUGEPAGED
>> * 0                             -> TVA_FORCED_COLLAPSE
>>
>> With this change, we immediately know if we are in the forced collapse
>> case, which will be valuable next.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> Acked-by: Usama Arif <usamaarif642@gmail.com>
>> Signed-off-by: Usama Arif <usamaarif642@gmail.com>
>> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> 
> Acked-by: Yafang Shao <laoar.shao@gmail.com>
> 
> Hello Usama,
> 
> This change is also required by my BPF-based THP order selection
> series [0]. Since this patch appears to be independent of the series,
> could we merge it first into mm-new or mm-everything if the series
> itself won't be merged shortly?
> 
> Link: https://lwn.net/Articles/1031829/ [0]
> 

Thanks for reviewing!

All of the patches in the series have several acks/reviews. Only a small change
might be required in selftest, so hopefully the next revision is the last one.

Andrew - would it be ok to start including this entire series in the mm-new now?

Thanks!