Re: [PATCH 2/3] mm: huge_memory: add thp_vma_disabled()

[David Hildenbrand <david@redhat.com>]

On 11.10.24 02:40, Kefeng Wang wrote:
> 
> 
> On 2024/10/10 22:53, David Hildenbrand wrote:
>> On 10.10.24 16:41, David Hildenbrand wrote:
>>> On 10.10.24 08:10, Kefeng Wang wrote:
>>>> Add thp_vma_disabled() helper to shared by shmem_allowable_huge_orders()
>>>> and __thp_vma_allowable_orders().
>>>>
>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>> ---
>>>>     include/linux/huge_mm.h | 19 +++++++++++++++++++
>>>>     mm/huge_memory.c        | 13 +------------
>>>>     mm/shmem.c              |  7 +------
>>>>     3 files changed, 21 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>> index 795df660efa5..d77891332b35 100644
>>>> --- a/include/linux/huge_mm.h
>>>> +++ b/include/linux/huge_mm.h
>>>> @@ -309,6 +309,25 @@ struct thpsize {
>>>>         (transparent_hugepage_flags &                    \
>>>>          (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG))
>>>> +static inline bool thp_vma_disabled(struct vm_area_struct *vma,
>>>> +                    unsigned long vm_flags)
>>>> +{
>>>>
>>>
>>> I might need a patch like this for an independent fix, and the more I
>>> look at this the more I hate the separate vm_flags and the optional vma
>>> argument.
> 
> Yes, it is a little strange when made this changes,  a separate vm_flags
> and another vma argument, most vm_flags is just vma->vm_flags(madvise is
> a special case).
> 

Yes, we should be able to handle the madvise stuff in a better way 
(simply check after the vma->vm_flags where modified).

>>>
>>> Let me try to improve things.
>>>
>>> Long term we can get rid of the vm_flags, it just needs some madvise()
>>> massaging.
>>
> 
> Thanks for your improvement, it is more accurate.

I will include that in my next small fix-series and CC you.

-- 
Cheers,

David / dhildenb