Re: [RFC PATCH v2 0/5] mm, bpf: BPF based THP adjustment

[Gutierrez Asier <gutierrez.asier@huawei-partners.com>]

On 5/26/2025 7:51 PM, David Hildenbrand wrote:
> On 26.05.25 17:54, Liam R. Howlett wrote:
>> * Liam R. Howlett <Liam.Howlett@oracle.com> [250526 10:54]:
>>> * David Hildenbrand <david@redhat.com> [250526 06:49]:
>>>> On 26.05.25 11:37, Yafang Shao wrote:
>>>>> On Mon, May 26, 2025 at 4:14 PM David Hildenbrand <david@redhat.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Let’s summarize the current state of the discussion and identify how
>>>>>>> to move forward.
>>>>>>>
>>>>>>> - Global-Only Control is Not Viable
>>>>>>> We all seem to agree that a global-only control for THP is unwise. In
>>>>>>> practice, some workloads benefit from THP while others do not, so a
>>>>>>> one-size-fits-all approach doesn’t work.
>>>>>>>
>>>>>>> - Should We Use "Always" or "Madvise"?
>>>>>>> I suspect no one would choose 'always' in its current state. ;)
>>>>>>
>>>>>> IIRC, RHEL9 has the default set to "always" for a long time.
>>>>>
>>>>> good to know.
>>>>>
>>>>>>
>>>>>> I guess it really depends on how different the workloads are that you
>>>>>> are running on the same machine.
>>>>>
>>>>> Correct. If we want to enable THP for specific workloads without
>>>>> modifying the kernel, we must isolate them on dedicated servers.
>>>>> However, this approach wastes resources and is not an acceptable
>>>>> solution.
>>>>>
>>>>>>
>>>>>>    > Both Lorenzo and David propose relying on the madvise mode. However,>
>>>>>> since madvise is an unprivileged userspace mechanism, any user can
>>>>>>> freely adjust their THP policy. This makes fine-grained control
>>>>>>> impossible without breaking userspace compatibility—an undesirable
>>>>>>> tradeoff.
>>>>>>
>>>>>> If required, we could look into a "sealing" mechanism, that would
>>>>>> essentially lock modification attempts performed by the process (i.e.,
>>>>>> MADV_HUGEPAGE).
>>>>>
>>>>> If we don’t introduce a new THP mode and instead rely solely on
>>>>> madvise, the "sealing" mechanism could either violate the intended
>>>>> semantics of madvise(), or simply break madvise() entirely, right?
>>>>
>>>> We would have to be a bit careful, yes.
>>>>
>>>> Errors from MADV_HUGEPAGE/MADV_NOHUGEPAGE are often ignored, because these
>>>> options also fail with -EINVAL on kernels without THP support.
>>>>
>>>> Ignoring MADV_NOHUGEPAGE can be problematic with userfaultfd.
>>>>
>>>> What you likely really want to do is seal when you configured
>>>> MADV_NOHUGEPAGE to be the default, and fail MADV_HUGEPAGE later.
>>
>> I am also not entirely sure how sealing a non-existing vma would work.
>> We'd have to seal the default flags, but sealing is one way and this
>> surely shouldn't be one way?
> 
> You probably have  mseal() in mind. Just like we wouldn't be using madvise(), we also wouldn't be using mseal().
> 
> It could be a simple mctrl()/whatever option/flag to set the default and no longer allow changing the default and per-VMA flags, unless CAP_SYS_ADMIN or sth like that.
> 

This isn't really TRANSPARENT Huge Pages, since we will require 
the application to determine which memory range will be mapped with 
huge pages.

-- 
Asier Gutierrez
Huawei