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

[David Hildenbrand]

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