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

[David Hildenbrand <david@redhat.com>]

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.

-- 
Cheers,

David / dhildenb