Message-ID: <02ead03b-339b-45c8-b252-d31a66501c39@lucifer.local>
Date: Thu, 15 May 2025 17:06:46 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Usama Arif <usamaarif642@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, david@...hat.com,
        linux-mm@...ck.org, hannes@...xchg.org, shakeel.butt@...ux.dev,
        riel@...riel.com, ziy@...dia.com, laoar.shao@...il.com,
        baolin.wang@...ux.alibaba.com, Liam.Howlett@...cle.com,
        npache@...hat.com, ryan.roberts@....com, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT_HUGE for the
 process

On Thu, May 15, 2025 at 04:28:51PM +0100, Usama Arif wrote:
>
>
> On 15/05/2025 15:40, Lorenzo Stoakes wrote:
> > Overall I feel this series should _DEFINITELY_ be an RFC. This is pretty
> > outlandish stuff and needs discussion.
> >
>
> There was a lot of discussion in the
> original patch (https://lore.kernel.org/linux-mm/20250507141132.2773275-1-usamaarif642@gmail.com/).
> And there was a conclusion to go with Davids suggestion (https://lore.kernel.org/all/13b68fa0-8755-43d8-8504-d181c2d46134@gmail.com/)
> and the following reply (https://lore.kernel.org/all/97702ff0-fc50-4779-bfa8-83dc42352db1@redhat.com/)
>
>
> > You're basically making it so /sys/kernel/mm/transparent_hugepage/enabled =
> > never is completely ignored and overridden. Which I am emphatically not
> > comfortable with. And you're not saying that you're doing this,
> > anywhere. Which is wrong.
>
> No I am not.
>
> hugepage_global_always and hugepage_global_enabled will evaluate to false
> and you will not get a hugepage.

Ack yes as discussed elsewhere.

However again, as discussed elsewhere, you are setting the MMF and VMA
flags without accounting for the logic in hugepage_madvise().

>
> >
> > Also, this patch is quite broken.
> >
> > I'm hugely not a fan of adding mm_struct->flags2, and I'm even more not a
> > fan of you not mentioning such a completely fundamental change in the
> > commit mesage.
>
> This was also discussed in the original series.

It being discussed in the other series doesn't mean we can no longer
discuss it :)

>
> If there is a very serious issue with going with flags2, I can try and just
> reuse mm->flags bit 18, but it will mean that only MMF2_THP_VMA_DEFAULT_HUGE
> can be implemented and not MMF2_THP_VMA_DEFAULT_NOHUGE

I have a big problem with us fundamentally changing a core mm data
structure for what appear to be very specific purposes, yes.

But I think we have a better solution... see below

>
> We have run out of bits in mm->flags.
> If there is something new that we are developing that needs another bit,
> we either need to add flags2 (I don't care about the name, can be anything),
> or we need to limit it to 64 bit machines only.
>
> If the maintainers have an issue with flags2. I can limit this to 64 bits,
> it will probably mean ifdefs everywhere...

I'm a maintainer also good sir :)

As I say elsewhere, we could make a pre-requisite change of making
mm->flags 64-bit even on 32-bit kernels.

This is a change that I will be doing to vma->vm_flags soon as I have the
exact same problem, and it's very silly indeed.

Adding 8 bytes per process for every single process everywhere just for
this to suit essentially deprecated kernels is... not ideal :)

But also there's further issues with having 2 flags fields, I discuss
elsewhere in this semi-stream-of-consciousness..

>
> >
> > This patch also breaks VMA merging and the VMA tests...
> >
>
> Its doing the same as KSM as suggested by David. Does KSM break these tests?
> Is there some specific test you can point to that I can run that is breaking
> with this patch and not without it?

They don't build, at all. I explain how you can attempt a build below.

And no, KSM doesn't break the tests, because steps were taken to make them
not break the tests :) I mean it's really easy - it's just adding some
trivial stubs.

If you need help with it just ping me in whatever way helps and I can help!

It's understandable as it's not necessarily clear this is a thing (maybe we
need self tests to build it, but that might break CI setups so unclear).

The merging is much more important!

>
>
> > I really feel this series needs to be an RFC until we can get some
> > consensus on how to approach this.
>
> There was consensus in https://lore.kernel.org/all/97702ff0-fc50-4779-bfa8-83dc42352db1@redhat.com/

I disagree with this asssessment, that doesn't look like consensus at all,
I think at least this is a very contentious or at least _complicated_ topic
that we need to really dig into.

So in my view - it's this kind of situation that warrants an RFC until
there's some stabilisation and agreement on a way forward.

>
> >
> > On Thu, May 15, 2025 at 02:33:30PM +0100, Usama Arif wrote:
> >> This is set via the new PR_SET_THP_POLICY prctl.
> >
> > What is?
> >
> > You're making very major changes here, including adding a new flag to
> > mm_struct (!!) and the explanation/justification for this is missing.
> >
>
> I have added the justification in your reply to the coverletter.

As stated there, you've not explained why alternatives are unworkable, I
think we need this!

Sort of:

1. Why not cgroups? blah blah blah
2. Why not process_madvise()? blah blah blah
3. Why not bpf? blah blah blah
4. Why not <something I've not thought of>? blah blah blah

>
> >> This will set the MMF2_THP_VMA_DEFAULT_HUGE process flag
> >> which changes the default of new VMAs to be VM_HUGEPAGE. The
> >> call also modifies all existing VMAs that are not VM_NOHUGEPAGE
> >> to be VM_HUGEPAGE. The policy is inherited during fork+exec.
> >
> > So you can only set this flag?
> >
>
> ??

This patch is only allowing the setting of this flag. I am asking 'so you
can only set this flag?'

To which it appears the answer is, yes I think :)

An improved cover letter could say something like:

"
Here we implement the first flag intended to allow the _overriding_ of huge
page policy to ensure that, when
/sys/kernel/mm/transparent_hugepage/enabled is set to madvise, we are able
to maintain fine-grained control of individual processes, including any
fork/exec'd, by setting this flag.

In subsequent commits, we intend to permit further such control.
"

>
> >>
> >> This allows systems where the global policy is set to "madvise"
> >> to effectively have THPs always for the process. In an environment
> >> where different types of workloads are stacked on the same machine,
> >> this will allow workloads that benefit from always having hugepages
> >> to do so, without regressing those that don't.
> >
> > Again, this explanation really makes no sense at all to me, I don't really
> > know what you mean, you're not going into what you're doing in this change,
> > this is just a very unclear commit message.
> >
>
> I hope this is answered in my reply to your coverletter.

You still need to improve the cover letter here I think, see above for a
suggestion!

>
> >>
> >> Signed-off-by: Usama Arif <usamaarif642@...il.com>
> >> ---
> >>  include/linux/huge_mm.h                       |  3 ++
> >>  include/linux/mm_types.h                      | 11 +++++++
> >>  include/uapi/linux/prctl.h                    |  4 +++
> >>  kernel/fork.c                                 |  1 +
> >>  kernel/sys.c                                  | 21 ++++++++++++
> >>  mm/huge_memory.c                              | 32 +++++++++++++++++++
> >>  mm/vma.c                                      |  2 ++
> >>  tools/include/uapi/linux/prctl.h              |  4 +++
> >>  .../trace/beauty/include/uapi/linux/prctl.h   |  4 +++
> >>  9 files changed, 82 insertions(+)
> >>
> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> >> index 2f190c90192d..e652ad9ddbbd 100644
> >> --- a/include/linux/huge_mm.h
> >> +++ b/include/linux/huge_mm.h
> >> @@ -260,6 +260,9 @@ static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
> >>  	return orders;
> >>  }
> >>
> >> +void vma_set_thp_policy(struct vm_area_struct *vma);
> >
> > This is a VMA-specific function but you're putting it in huge_mm.h? Why
> > can't
> this be in vma.h or vma.c?
> >
>
> Sure can move it there.
>
> >> +void process_vmas_thp_default_huge(struct mm_struct *mm);
> >
> > 'vmas' is redundant here.
> >
>
> Sure.
> >> +
> >>  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >>  					 unsigned long vm_flags,
> >>  					 unsigned long tva_flags,
> >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> >> index e76bade9ebb1..2fe93965e761 100644
> >> --- a/include/linux/mm_types.h
> >> +++ b/include/linux/mm_types.h
> >> @@ -1066,6 +1066,7 @@ struct mm_struct {
> >>  		mm_context_t context;
> >>
> >>  		unsigned long flags; /* Must use atomic bitops to access */
> >> +		unsigned long flags2;
> >
> >
> > Ugh, god really??
> >
> > I really am not a fan of adding flags2 just to add a prctl() feature like
> > this. This is crazy.
> >
> > Also this is a TERRIBLE name. I mean, no please PLEASE no.
> >
> > Do we really have absolutely no choice but to add a new flags field here?
> >
> > It again doesn't help that you don't mention nor even try to justify this
> > in the commit message or cover letter.
> >
>
> And again, I hope my reply to your email has given you the justification.

No :) I understood why you did this though of course.

>
> > If this is a 32-bit kernel vs. 64-bit kernel thing so we 'ran out of bits',
> > let's just go make this flags field 64-bit on 32-bit kernels.
> >
> > I mean - I'm kind of insisting we do that to be honest. Because I really
> > don't like this.
>
>
> If the maintainers want this, I will make it a 64 bit only feature. We
> are only using it for 64 bit servers. But it will probably mean ifdef
> config 64 bit in a lot of places.

I'm going to presume you are including me in this category rather than
implying that you are deferring only to others :)

So, there's another option:

Have a prerequisite series that makes mm_struct->flags 64-bit on 32-bit
kernels, which solves this problem everywhere and avoids us wasting a bunch
of memory for a very specific usecase, splitting flag state across 2 fields
(which are no longer atomic as a whole of course), adding confusion,
possibly subtly breaking anywhere that assumes mm->flags completely
describes mm-granularity flag state etc.

The RoI here is not looking good, otherwise.

>
> >
> > Also if we _HAVE_ to have this, shouldn't we duplicate that comment about
> > atomic bitops?...
> >
>
> Sure
>
> >>
> >>  #ifdef CONFIG_AIO
> >>  		spinlock_t			ioctx_lock;
> >> @@ -1744,6 +1745,11 @@ enum {
> >>  				 MMF_DISABLE_THP_MASK | MMF_HAS_MDWE_MASK |\
> >>  				 MMF_VM_MERGE_ANY_MASK | MMF_TOPDOWN_MASK)
> >>
> >> +#define MMF2_THP_VMA_DEFAULT_HUGE		0
> >
> > I thought the whole idea was to move away from explicitly refrencing 'THP'
> > in a future where large folios are implicit and now we're saying 'THP'.
> >
> > Anyway the 'VMA' is totally redundant here.
> >
>
> Sure, I can remove VMA.
> I see THP everywhere in the kernel code.
> Its mentioned 108 times in transhuge.rst alone :)
> If you have any suggestion to rename this flag, happy to take it :)

Yeah I mean it's a mess man, and it's not your fault... Again naming is
hard, I put a suggestion in reply to cover letter anyway...

>
> >> +#define MMF2_THP_VMA_DEFAULT_HUGE_MASK		(1 << MMF2_THP_VMA_DEFAULT_HUGE)
> >
> > Do we really need explicit trivial mask declarations like this?
> >
>
> I have followed the convention that has existed in this file, please see below
> links :)
> https://elixir.bootlin.com/linux/v6.14.6/source/include/linux/mm_types.h#L1645
> https://elixir.bootlin.com/linux/v6.14.6/source/include/linux/mm_types.h#L1623
> https://elixir.bootlin.com/linux/v6.14.6/source/include/linux/mm_types.h#L1603
> https://elixir.bootlin.com/linux/v6.14.6/source/include/linux/mm_types.h#L1582

Ack, yuck but ack.

>
>
> >> +
> >> +#define MMF2_INIT_MASK		(MMF2_THP_VMA_DEFAULT_HUGE_MASK)
> >
> >> +
> >>  static inline unsigned long mmf_init_flags(unsigned long flags)
> >>  {
> >>  	if (flags & (1UL << MMF_HAS_MDWE_NO_INHERIT))
> >> @@ -1752,4 +1758,9 @@ static inline unsigned long mmf_init_flags(unsigned long flags)
> >>  	return flags & MMF_INIT_MASK;
> >>  }
> >>
> >> +static inline unsigned long mmf2_init_flags(unsigned long flags)
> >> +{
> >> +	return flags & MMF2_INIT_MASK;
> >> +}
> >> +
> >>  #endif /* _LINUX_MM_TYPES_H */
> >> diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> >> index 15c18ef4eb11..325c72f40a93 100644
> >> --- a/include/uapi/linux/prctl.h
> >> +++ b/include/uapi/linux/prctl.h
> >> @@ -364,4 +364,8 @@ struct prctl_mm_map {
> >>  # define PR_TIMER_CREATE_RESTORE_IDS_ON		1
> >>  # define PR_TIMER_CREATE_RESTORE_IDS_GET	2
> >>
> >> +#define PR_SET_THP_POLICY		78
> >> +#define PR_GET_THP_POLICY		79
> >> +#define PR_THP_POLICY_DEFAULT_HUGE	0
> >> +
> >>  #endif /* _LINUX_PRCTL_H */
> >> diff --git a/kernel/fork.c b/kernel/fork.c
> >> index 9e4616dacd82..6e5f4a8869dc 100644
> >> --- a/kernel/fork.c
> >> +++ b/kernel/fork.c
> >> @@ -1054,6 +1054,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
> >>
> >>  	if (current->mm) {
> >>  		mm->flags = mmf_init_flags(current->mm->flags);
> >> +		mm->flags2 = mmf2_init_flags(current->mm->flags2);
> >>  		mm->def_flags = current->mm->def_flags & VM_INIT_DEF_MASK;
> >>  	} else {
> >>  		mm->flags = default_dump_filter;
> >> diff --git a/kernel/sys.c b/kernel/sys.c
> >> index c434968e9f5d..1115f258f253 100644
> >> --- a/kernel/sys.c
> >> +++ b/kernel/sys.c
> >> @@ -2658,6 +2658,27 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> >>  			clear_bit(MMF_DISABLE_THP, &me->mm->flags);
> >>  		mmap_write_unlock(me->mm);
> >>  		break;
> >> +	case PR_GET_THP_POLICY:
> >> +		if (arg2 || arg3 || arg4 || arg5)
> >> +			return -EINVAL;
> >> +		if (!!test_bit(MMF2_THP_VMA_DEFAULT_HUGE, &me->mm->flags2))
> >
> > I really don't think we need the !!? Do we?
>
> I have followed the convention that has existed in this file already,
> please see:
> https://elixir.bootlin.com/linux/v6.14.6/source/kernel/sys.c#L2644

OK, but please don't, I don't see why this is necessary. if (truthy) is
fine.

Unless somebody has a really good reason why this is necessary, it's just
ugly ceremony.

>
> >
> > Shouldn't we lock the mm when we do this no? Can't somebody change this?
> >
>
> It wasn't locked in PR_GET_THP_DISABLE
> https://elixir.bootlin.com/linux/v6.14.6/source/kernel/sys.c#L2644
>
> I can acquire do mmap_write_lock_killable the same as PR_SET_THP_POLICY
> in the next series.
>
> I can also add the lock in PR_GET_THP_DISABLE.

Well, the issue I guess is... if the flags field is atomic, and we know
over this call maybe we can rely on mm sticking around, then we probalby
don't need an mmap lock actually.

>
> >> +			error = PR_THP_POLICY_DEFAULT_HUGE;

Wait, error = PR_THP_POLICY_DEFAULT_HUGE? Is this the convention for
returning here? :)

> >> +		break;
> >> +	case PR_SET_THP_POLICY:
> >> +		if (arg3 || arg4 || arg5)
> >> +			return -EINVAL;
> >> +		if (mmap_write_lock_killable(me->mm))
> >> +			return -EINTR;
> >> +		switch (arg2) {
> >> +		case PR_THP_POLICY_DEFAULT_HUGE:
> >> +			set_bit(MMF2_THP_VMA_DEFAULT_HUGE, &me->mm->flags2);
> >> +			process_vmas_thp_default_huge(me->mm);
> >> +			break;
> >> +		default:
> >> +			return -EINVAL;

Oh I just noticed - this is really broken - you're not unlocking the mmap()
here on error... :) you definitely need to fix this.

> >> +		}
> >> +		mmap_write_unlock(me->mm);
> >> +		break;
> >>  	case PR_MPX_ENABLE_MANAGEMENT:
> >>  	case PR_MPX_DISABLE_MANAGEMENT:
> >>  		/* No longer implemented: */
> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >> index 2780a12b25f0..64f66d5295e8 100644
> >> --- a/mm/huge_memory.c
> >> +++ b/mm/huge_memory.c
> >> @@ -98,6 +98,38 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
> >>  	return !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
> >>  }
> >>
> >> +void vma_set_thp_policy(struct vm_area_struct *vma)
> >> +{
> >> +	struct mm_struct *mm = vma->vm_mm;
> >> +
> >> +	if (test_bit(MMF2_THP_VMA_DEFAULT_HUGE, &mm->flags2))
> >> +		vm_flags_set(vma, VM_HUGEPAGE);
> >> +}
> >> +
> >> +static void vmas_thp_default_huge(struct mm_struct *mm)
> >> +{
> >> +	struct vm_area_struct *vma;
> >> +	unsigned long vm_flags;
> >> +
> >> +	VMA_ITERATOR(vmi, mm, 0);
> >
> > This is a declaration, it should be grouped with declarations...
> >
>
> Sure, will make the change in next version.
>
> Unfortunately checkpatch didn't complain.

Checkpatch actually complains the other way :P it doesn't understand
macros.

So you'll start getting a warning here, which you can ignore. It sucks, but
there we go. Making checkpatch.pl understand that would be a pain, probs.

>
> >> +	for_each_vma(vmi, vma) {
> >> +		vm_flags = vma->vm_flags;
> >> +		if (vm_flags & VM_NOHUGEPAGE)
> >> +			continue;
> >
> > Literally no point in you putting vm_flags as a separate variable here.
> >
>
> Sure, will make the change in next version.

Thanks!

>
> > So if you're not overriding VM_NOHUGEPAGE, the whole point of this exercise
> > is to override global 'never'?
> >
>
> Again, I am not overriding never.
>
> hugepage_global_always and hugepage_global_enabled will evaluate to false
> and you will not get a hugepage.

Yeah, again ack, but I kind of hate that we set VM_HUGEPAGE everywhere even
if the policy is never.

And we now get into realms of:

'Hey I set prctl() to make everything huge pages, and PR_GET_THP_POLICY
says I've set that, but nothing is huge? BUG???'

Of course then you get into - if somebody sets it to never, do we go around
and remove VM_HUGEPAGE and this MMF_ flag?

>
>
> > I'm really concerned about this.
> >
> >> +		vm_flags_set(vma, VM_HUGEPAGE);
> >> +	}
> >> +}
> >
> > Do we have an mmap write lock established here? Can you confirm that? Also
> > you should add an assert for that here.
> >
>
> Yes I do, its only called in PR_SET_THP_POLICY where mmap_write lock was taken.
> I can add an assert if it helps.

It not only helps, it's utterly critical :)

'It's only called in xxx()' is famous last words for a programmer, because
later somebody (maybe even your good self) calls it from somewhere else
and... we've all been there...

>
> >> +
> >> +void process_vmas_thp_default_huge(struct mm_struct *mm)
> >> +{
> >> +	if (test_bit(MMF2_THP_VMA_DEFAULT_HUGE, &mm->flags2))
> >> +		return;
> >> +
> >> +	set_bit(MMF2_THP_VMA_DEFAULT_HUGE, &mm->flags2);
> >> +	vmas_thp_default_huge(mm);
> >> +}
> >> +
> >> +
> >>  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >>  					 unsigned long vm_flags,
> >>  					 unsigned long tva_flags,
> >> diff --git a/mm/vma.c b/mm/vma.c
> >> index 1f2634b29568..101b19c96803 100644
> >> --- a/mm/vma.c
> >> +++ b/mm/vma.c
> >> @@ -2476,6 +2476,7 @@ static int __mmap_new_vma(struct mmap_state *map, struct vm_area_struct **vmap)
> >>  	if (!vma_is_anonymous(vma))
> >>  		khugepaged_enter_vma(vma, map->flags);
> >>  	ksm_add_vma(vma);
> >> +	vma_set_thp_policy(vma);
> >
> > You're breaking VMA merging completely by doing this here...
> >
> > Now I can map one VMA with this policy set, then map another immediately
> > next to it and - oops - no merge, ever, because the VM_HUGEPAGE flag is not
> > set in the new VMA on merge attempt.
> >
> > I realise KSM is just as broken (grr) but this doesn't justify us
> > completely breaking VMA merging here.
>
> I think this answers it. Its doing the same as KSM.

Yes, but as I said there, it's not acceptable, at all.

You're making it so litearlly VMA merging _does not happen at all_. That's
unacceptable and might even break some workloads.

You'll certainly cause very big kernel metadata usage.

Consider:

|-----------------------------|..................|
| some VMA flags, VM_HUGEPAGE | proposed new VMA |
|-----------------------------|..................|

Now, because you set VM_HUGEPAGE _after any merge is attempted_, this will
_always_ be fragmented, forever.

That's just not... acceptable.

The fact KSM is broken this way doesn't make that OK.

Especially on brk(), which now will _always_ allocate new VMAs for every
brk() expansion which doesn't seem very efficient.

It may also majorly degrade performance.

That makes me think we need some perf testing for this ideally...

>
> >
> > You need to set earlier than this. Then of course a driver might decide to
> > override this, so maybe then we need to override that.
> >
> > But then we're getting into realms of changing fundamental VMA code _just
> > for this feature_.
> >
> > Again I'm iffy about this. Very.
> >
> > Also you've broken the VMA userland tests here:
> >
> > $ cd tools/testing/vma
> > $ make
> > ...
> > In file included from vma.c:33:
> > ../../../mm/vma.c: In function ‘__mmap_new_vma’:
> > ../../../mm/vma.c:2486:9: error: implicit declaration of function ‘vma_set_thp_policy’; did you mean ‘vma_dup_policy’? [-Wimplicit-function-declaration]
> >  2486 |         vma_set_thp_policy(vma);
> >       |         ^~~~~~~~~~~~~~~~~~
> >       |         vma_dup_policy
> > make: *** [<builtin>: vma.o] Error 1
> >
> > You need to create stubs accordingly.
> >
>
> Thanks will do.

Thanks!

>
> >>  	*vmap = vma;
> >>  	return 0;
> >>
> >> @@ -2705,6 +2706,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma,
> >>  	mm->map_count++;
> >>  	validate_mm(mm);
> >>  	ksm_add_vma(vma);
> >> +	vma_set_thp_policy(vma);
> >
> > You're breaking merging again... This is quite a bad case too as now you'll
> > have totally fragmented brk VMAs no?
> >
>
> Again doing it the same as KSM.

That doesn't make it ok. Just because KSM is broken doesn't make this ok. I
mean grr at KSM :) I'm going to look into that and see about
investigating/fixing that behaviour.

obviously I can't accept anything that will fundamentally break VMA
merging.

The answer really is to do this earlier, but you risk a driver overriding
it, but that's OK I think (I don't even think any in-tree ones do actually
_anywhere_ - and yes I was literally reading through _every single_ .mmap()
callback lately because I am quite obviously insane ;)

Again I can help with this.

>
> > We can't have it implemented this way.
> >
> >>  out:
> >>  	perf_event_mmap(vma);
> >>  	mm->total_vm += len >> PAGE_SHIFT;
> >> diff --git a/tools/include/uapi/linux/prctl.h b/tools/include/uapi/linux/prctl.h
> >> index 35791791a879..f5945ebfe3f2 100644
> >> --- a/tools/include/uapi/linux/prctl.h
> >> +++ b/tools/include/uapi/linux/prctl.h
> >> @@ -328,4 +328,8 @@ struct prctl_mm_map {
> >>  # define PR_PPC_DEXCR_CTRL_CLEAR_ONEXEC	0x10 /* Clear the aspect on exec */
> >>  # define PR_PPC_DEXCR_CTRL_MASK		0x1f
> >>
> >> +#define PR_SET_THP_POLICY		78
> >> +#define PR_GET_THP_POLICY		79
> >> +#define PR_THP_POLICY_DEFAULT_HUGE	0
> >> +
> >>  #endif /* _LINUX_PRCTL_H */
> >> diff --git a/tools/perf/trace/beauty/include/uapi/linux/prctl.h b/tools/perf/trace/beauty/include/uapi/linux/prctl.h
> >> index 15c18ef4eb11..325c72f40a93 100644
> >> --- a/tools/perf/trace/beauty/include/uapi/linux/prctl.h
> >> +++ b/tools/perf/trace/beauty/include/uapi/linux/prctl.h
> >> @@ -364,4 +364,8 @@ struct prctl_mm_map {
> >>  # define PR_TIMER_CREATE_RESTORE_IDS_ON		1
> >>  # define PR_TIMER_CREATE_RESTORE_IDS_GET	2
> >>
> >> +#define PR_SET_THP_POLICY		78
> >> +#define PR_GET_THP_POLICY		79
> >> +#define PR_THP_POLICY_DEFAULT_HUGE	0
> >> +
> >>  #endif /* _LINUX_PRCTL_H */
> >> --
> >> 2.47.1
> >>
>

Powered by blists - more mailing lists