Re: [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are disabled

[David Hildenbrand <david@redhat.com>]

On 25.06.25 09:49, David Hildenbrand wrote:
> On 25.06.25 09:42, Lorenzo Stoakes wrote:
>> On Wed, Jun 25, 2025 at 09:36:53AM +0200, David Hildenbrand wrote:
>>> On 25.06.25 09:30, Lorenzo Stoakes wrote:
>>>> I _guarantee_ you that's what nearly everybody except a handful of people will
>>>> expect.
>>>
>>> I know, See my other mail, the problem is rather if there is no somebody
>>> relying on never+MADV_COLLAPSE from doing the MADV_COLLAPSE-documented
>>> thing.
>>>
>>> It's a mess.
>>
>> Well now we have an almost philosophical debate - we have different sets of
>> users, 99% of whom believe the uAPI is X, and 1% of whom believe it is Y.
>>
>> Now what is the uAPI? What is 'breaking userspace'? :)
> 
> Yeah, that's why I mentioned that I think we broke "something" when we
> changed the semantics. But that breakage probably only affects real
> corner cases (debugging, customer workarounds).
> 
> I think the whole use case of using MADV_COLLAPSE to completely control
> THP allocation in a system is otherwise pretty hard to achieve, if there
> is no other way to tame THP allocation through page faults+khugepaged.

Just want to add: for an app itself, it's doable in "madvise" mode 
perfectly fine.

If your app does a MADV_HUGEPAGE, it can get a THP during page-fault + 
khugepaged.

If your app does not do a MADV_HUGEPAGE, it can get a THP through 
MADV_COLLAPSE.

So the "madvise" mode actually works.



The problem appears as soon as we want to control other processes that 
might be setting MADV_HUGEPAGE, and we actually want to control the 
behavior using process_madvise(MADV_COLLAPSE), to say "well, the 
MADV_HUGEPAGE" should be ignored.

Then, you configure "never" system-wide and use 
process_madvise(MADV_COLLAPSE) to drive it all manually.

Curious to learn if there is such a user out there.

-- 
Cheers,

David / dhildenb