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

[David Hildenbrand <david@redhat.com>]

On 26.05.25 22:30, Gutierrez Asier wrote:
> 
> 
> 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.

Huh? No idea how you concluded that. Can you elaborate?

-- 
Cheers,

David / dhildenb