This series allows to change the THP policy of a process, according to the
value set in arg2, all of which will be inherited during fork+exec:
- PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
  for the default VMA flags. It will also iterate through every VMA in the
  process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
  This effectively allows setting MADV_HUGEPAGE on the entire process.
  In an environment where different types of workloads are run on the
  same machine, this will allow workloads that benefit from always having
  hugepages to do so, without regressing those that don't.
- PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
  for the default VMA flags. It will also iterate through every VMA in the
  process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
  This effectively allows setting MADV_NOHUGEPAGE on the entire process.
  In an environment where different types of workloads are run on the
  same machine,this will allow workloads that benefit from having
  hugepages on an madvise basis only to do so, without regressing those
  that benefit from having hugepages always.
- PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
  VM_NOHUGEPAGE process for the default flags.

In hyperscalers, we have a single THP policy for the entire fleet.
We have different types of workloads (e.g. AI/compute/databases/etc)
running on a single server.
Some of these workloads will benefit from always getting THP at fault
(or collapsed by khugepaged), some of them will benefit by only getting
them at madvise.

This series is useful for 2 usecases:
1) global system policy = madvise, while we want some workloads to get THPs
at fault and by khugepaged :- some processes (e.g. AI workloads) benefits
from getting THPs at fault (and collapsed by khugepaged). Other workloads
like databases will incur regression (either a performance regression or
they are completely memory bound and even a very slight increase in memory
will cause them to OOM). So what these patches will do is allow setting
prctl(PR_DEFAULT_MADV_HUGEPAGE) on the AI workloads, (This is how
workloads are deployed in our (Meta's/Facebook) fleet at this moment).

2) global system policy = always, while we want some workloads to get THPs
only on madvise basis :- Same reason as 1). What these patches
will do is allow setting prctl(PR_DEFAULT_MADV_NOHUGEPAGE) on the database
workloads. (We hope this is us (Meta) in the near future, if a majority of
workloads show that they benefit from always, we flip the default host
setting to "always" across the fleet and workloads that regress can opt-out
and be "madvise". New services developed will then be tested with always by
default. "always" is also the default defconfig option upstream, so I would
imagine this is faced by others as well.)

v2->v3: (Thanks Lorenzo for all the below feedback!)
v2: https://lore.kernel.org/all/20250515133519.2779639-1-usamaarif642@gmail.com/
- no more flags2.
- no more MMF2_...
- renamed policy to PR_DEFAULT_MADV_(NO)HUGEPAGE
- mmap_write_lock_killable acquired in PR_GET_THP_POLICY
- mmap_write lock fixed in PR_SET_THP_POLICY
- mmap assert check in process_default_madv_hugepage
- check if hugepage_global_enabled is enabled in the call and account for s390
- set mm->def_flags VM_HUGEPAGE and VM_NOHUGEPAGE according to the policy in
  the way done by madvise(). I believe VM merge will not be broken in
  this way.
- process_default_madv_hugepage function that does for_each_vma and calls
  hugepage_madvise.

v1->v2:
- change from modifying the THP decision making for the process, to modifying
  VMA flags only. This prevents further complicating the logic used to
  determine THP order (Thanks David!)
- change from using a prctl per policy change to just using PR_SET_THP_POLICY
  and arg2 to set the policy. (Zi Yan)
- Introduce PR_THP_POLICY_DEFAULT_NOHUGE and PR_THP_POLICY_DEFAULT_SYSTEM
- Add selftests and documentation.
 
Usama Arif (7):
  mm: khugepaged: extract vm flag setting outside of hugepage_madvise
  prctl: introduce PR_DEFAULT_MADV_HUGEPAGE for the process
  prctl: introduce PR_DEFAULT_MADV_NOHUGEPAGE for the process
  prctl: introduce PR_THP_POLICY_SYSTEM for the process
  selftests: prctl: introduce tests for PR_DEFAULT_MADV_NOHUGEPAGE
  selftests: prctl: introduce tests for PR_THP_POLICY_DEFAULT_HUGE
  docs: transhuge: document process level THP controls

 Documentation/admin-guide/mm/transhuge.rst    |  42 +++
 include/linux/huge_mm.h                       |   2 +
 include/linux/mm.h                            |   2 +-
 include/linux/mm_types.h                      |   4 +-
 include/uapi/linux/prctl.h                    |   6 +
 kernel/sys.c                                  |  53 ++++
 mm/huge_memory.c                              |  13 +
 mm/khugepaged.c                               |  26 +-
 tools/include/uapi/linux/prctl.h              |   6 +
 .../trace/beauty/include/uapi/linux/prctl.h   |   6 +
 tools/testing/selftests/prctl/Makefile        |   2 +-
 tools/testing/selftests/prctl/thp_policy.c    | 286 ++++++++++++++++++
 12 files changed, 436 insertions(+), 12 deletions(-)
 create mode 100644 tools/testing/selftests/prctl/thp_policy.c

-- 
2.47.1

(cc'ing linux-api)

On Mon, May 19, 2025 at 11:29:52PM +0100, Usama Arif wrote:
> This series allows to change the THP policy of a process, according to the
> value set in arg2, all of which will be inherited during fork+exec:
> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
>   This effectively allows setting MADV_HUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine, this will allow workloads that benefit from always having
>   hugepages to do so, without regressing those that don't.
> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
>   This effectively allows setting MADV_NOHUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine,this will allow workloads that benefit from having
>   hugepages on an madvise basis only to do so, without regressing those
>   that benefit from having hugepages always.
> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
>   VM_NOHUGEPAGE process for the default flags.
> 
> In hyperscalers, we have a single THP policy for the entire fleet.
> We have different types of workloads (e.g. AI/compute/databases/etc)
> running on a single server.
> Some of these workloads will benefit from always getting THP at fault
> (or collapsed by khugepaged), some of them will benefit by only getting
> them at madvise.
> 
> This series is useful for 2 usecases:
> 1) global system policy = madvise, while we want some workloads to get THPs
> at fault and by khugepaged :- some processes (e.g. AI workloads) benefits
> from getting THPs at fault (and collapsed by khugepaged). Other workloads
> like databases will incur regression (either a performance regression or
> they are completely memory bound and even a very slight increase in memory
> will cause them to OOM). So what these patches will do is allow setting
> prctl(PR_DEFAULT_MADV_HUGEPAGE) on the AI workloads, (This is how
> workloads are deployed in our (Meta's/Facebook) fleet at this moment).
> 
> 2) global system policy = always, while we want some workloads to get THPs
> only on madvise basis :- Same reason as 1). What these patches
> will do is allow setting prctl(PR_DEFAULT_MADV_NOHUGEPAGE) on the database
> workloads. (We hope this is us (Meta) in the near future, if a majority of
> workloads show that they benefit from always, we flip the default host
> setting to "always" across the fleet and workloads that regress can opt-out
> and be "madvise". New services developed will then be tested with always by
> default. "always" is also the default defconfig option upstream, so I would
> imagine this is faced by others as well.)
> 
> v2->v3: (Thanks Lorenzo for all the below feedback!)
> v2: https://lore.kernel.org/all/20250515133519.2779639-1-usamaarif642@gmail.com/
> - no more flags2.
> - no more MMF2_...
> - renamed policy to PR_DEFAULT_MADV_(NO)HUGEPAGE
> - mmap_write_lock_killable acquired in PR_GET_THP_POLICY
> - mmap_write lock fixed in PR_SET_THP_POLICY
> - mmap assert check in process_default_madv_hugepage
> - check if hugepage_global_enabled is enabled in the call and account for s390
> - set mm->def_flags VM_HUGEPAGE and VM_NOHUGEPAGE according to the policy in
>   the way done by madvise(). I believe VM merge will not be broken in
>   this way.
> - process_default_madv_hugepage function that does for_each_vma and calls
>   hugepage_madvise.
> 
> v1->v2:
> - change from modifying the THP decision making for the process, to modifying
>   VMA flags only. This prevents further complicating the logic used to
>   determine THP order (Thanks David!)
> - change from using a prctl per policy change to just using PR_SET_THP_POLICY
>   and arg2 to set the policy. (Zi Yan)
> - Introduce PR_THP_POLICY_DEFAULT_NOHUGE and PR_THP_POLICY_DEFAULT_SYSTEM
> - Add selftests and documentation.
>  
> Usama Arif (7):
>   mm: khugepaged: extract vm flag setting outside of hugepage_madvise
>   prctl: introduce PR_DEFAULT_MADV_HUGEPAGE for the process
>   prctl: introduce PR_DEFAULT_MADV_NOHUGEPAGE for the process
>   prctl: introduce PR_THP_POLICY_SYSTEM for the process
>   selftests: prctl: introduce tests for PR_DEFAULT_MADV_NOHUGEPAGE
>   selftests: prctl: introduce tests for PR_THP_POLICY_DEFAULT_HUGE
>   docs: transhuge: document process level THP controls
> 
>  Documentation/admin-guide/mm/transhuge.rst    |  42 +++
>  include/linux/huge_mm.h                       |   2 +
>  include/linux/mm.h                            |   2 +-
>  include/linux/mm_types.h                      |   4 +-
>  include/uapi/linux/prctl.h                    |   6 +
>  kernel/sys.c                                  |  53 ++++
>  mm/huge_memory.c                              |  13 +
>  mm/khugepaged.c                               |  26 +-
>  tools/include/uapi/linux/prctl.h              |   6 +
>  .../trace/beauty/include/uapi/linux/prctl.h   |   6 +
>  tools/testing/selftests/prctl/Makefile        |   2 +-
>  tools/testing/selftests/prctl/thp_policy.c    | 286 ++++++++++++++++++
>  12 files changed, 436 insertions(+), 12 deletions(-)
>  create mode 100644 tools/testing/selftests/prctl/thp_policy.c
> 
> -- 
> 2.47.1
> 
> 

-- 
Sincerely yours,
Mike.

* Usama Arif <usamaarif642@gmail.com> [250519 18:34]:
> This series allows to change the THP policy of a process, according to the
> value set in arg2, all of which will be inherited during fork+exec:
> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
>   This effectively allows setting MADV_HUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine, this will allow workloads that benefit from always having
>   hugepages to do so, without regressing those that don't.
> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
>   This effectively allows setting MADV_NOHUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine,this will allow workloads that benefit from having
>   hugepages on an madvise basis only to do so, without regressing those
>   that benefit from having hugepages always.
> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
>   VM_NOHUGEPAGE process for the default flags.
> 

Subject seems outdated now?  PR_DEFAULT_ vs PR_SET/GET_THP ?

On that note, doesn't it make sense to change the default mm flag under
PR_SET_MM?  PR_SET_MM_FLAG maybe?

Thanks,
Liam

On 21/05/2025 03:33, Liam R. Howlett wrote:
> * Usama Arif <usamaarif642@gmail.com> [250519 18:34]:
>> This series allows to change the THP policy of a process, according to the
>> value set in arg2, all of which will be inherited during fork+exec:
>> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
>>   for the default VMA flags. It will also iterate through every VMA in the
>>   process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
>>   This effectively allows setting MADV_HUGEPAGE on the entire process.
>>   In an environment where different types of workloads are run on the
>>   same machine, this will allow workloads that benefit from always having
>>   hugepages to do so, without regressing those that don't.
>> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
>>   for the default VMA flags. It will also iterate through every VMA in the
>>   process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
>>   This effectively allows setting MADV_NOHUGEPAGE on the entire process.
>>   In an environment where different types of workloads are run on the
>>   same machine,this will allow workloads that benefit from having
>>   hugepages on an madvise basis only to do so, without regressing those
>>   that benefit from having hugepages always.
>> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
>>   VM_NOHUGEPAGE process for the default flags.
>>
> 
> Subject seems outdated now?  PR_DEFAULT_ vs PR_SET/GET_THP ?

No its not.

prctl takes 5 args, the first 2 are relevant here.

The first arg is to decide the op. This series introduces 2 ops. PR_SET_THP_POLICY
and PR_GET_THP_POLICY to set and get the policy. This is the subject.

The 2nd arg describes the policies: PR_DEFAULT_MADV_HUGEPAGE, PR_DEFAULT_MADV_NOHUGEPAGE
and PR_THP_POLICY_SYSTEM.

The subject is correct.

> 
> On that note, doesn't it make sense to change the default mm flag under
> PR_SET_MM?  PR_SET_MM_FLAG maybe?

I don't think thats the right approach. PR_SET_MM is used to modify kernel
memory map descriptor fields. Thats not what we are doing here.

I am not sure how the usecase in this series fits at all in the below 
switch statement for PR_SET_MM:

	switch (opt) {
	case PR_SET_MM_START_CODE:
		prctl_map.start_code = addr;
		break;
	case PR_SET_MM_END_CODE:
		prctl_map.end_code = addr;
		break;
	case PR_SET_MM_START_DATA:
		prctl_map.start_data = addr;
		break;
	case PR_SET_MM_END_DATA:
		prctl_map.end_data = addr;
		break;
	case PR_SET_MM_START_STACK:
		prctl_map.start_stack = addr;
		break;
	case PR_SET_MM_START_BRK:
		prctl_map.start_brk = addr;
		break;
	case PR_SET_MM_BRK:
		prctl_map.brk = addr;
		break;
	case PR_SET_MM_ARG_START:
		prctl_map.arg_start = addr;
		break;
	case PR_SET_MM_ARG_END:
		prctl_map.arg_end = addr;
		break;
	case PR_SET_MM_ENV_START:
		prctl_map.env_start = addr;
		break;
	case PR_SET_MM_ENV_END:
		prctl_map.env_end = addr;
		break;
	default:
		goto out;
	}


> 
> Thanks,
> Liam

* Usama Arif <usamaarif642@gmail.com> [250521 05:31]:
> 
> 
> On 21/05/2025 03:33, Liam R. Howlett wrote:
> > * Usama Arif <usamaarif642@gmail.com> [250519 18:34]:
> >> This series allows to change the THP policy of a process, according to the
> >> value set in arg2, all of which will be inherited during fork+exec:
> >> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
> >>   for the default VMA flags. It will also iterate through every VMA in the
> >>   process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
> >>   This effectively allows setting MADV_HUGEPAGE on the entire process.
> >>   In an environment where different types of workloads are run on the
> >>   same machine, this will allow workloads that benefit from always having
> >>   hugepages to do so, without regressing those that don't.
> >> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
> >>   for the default VMA flags. It will also iterate through every VMA in the
> >>   process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
> >>   This effectively allows setting MADV_NOHUGEPAGE on the entire process.
> >>   In an environment where different types of workloads are run on the
> >>   same machine,this will allow workloads that benefit from having
> >>   hugepages on an madvise basis only to do so, without regressing those
> >>   that benefit from having hugepages always.
> >> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
> >>   VM_NOHUGEPAGE process for the default flags.
> >>
> > 
> > Subject seems outdated now?  PR_DEFAULT_ vs PR_SET/GET_THP ?
> 
> No its not.
> 
> prctl takes 5 args, the first 2 are relevant here.
> 
> The first arg is to decide the op. This series introduces 2 ops. PR_SET_THP_POLICY
> and PR_GET_THP_POLICY to set and get the policy. This is the subject.
> 
> The 2nd arg describes the policies: PR_DEFAULT_MADV_HUGEPAGE, PR_DEFAULT_MADV_NOHUGEPAGE
> and PR_THP_POLICY_SYSTEM.
> 
> The subject is correct.

Thanks, that makes sense.  You are adding an entire new configuration
item to the prctl fun.

> 
> > 
> > On that note, doesn't it make sense to change the default mm flag under
> > PR_SET_MM?  PR_SET_MM_FLAG maybe?
> 
> I don't think thats the right approach. PR_SET_MM is used to modify kernel
> memory map descriptor fields. Thats not what we are doing here.

Fair enough, you are changing the memory map default flags for vmas.

So we are going to add another top level THP specific prctl that changes
flags, but now def_flags and that's communicated by the word POLICY.

I'm not sure this is the right approach either.

Thanks,
Liam

NACK the whole series.

Usama - I explicitly said make this an RFC, so we can see what this
approach _looks like_ to further examine it, to which you agreed. And now
you've sent it non-RFC. That's not acceptable.

If you agree to something in review, it's not then optional as to whether
you do it.

Thanks.

On Mon, May 19, 2025 at 11:29:52PM +0100, Usama Arif wrote:
> This series allows to change the THP policy of a process, according to the
> value set in arg2, all of which will be inherited during fork+exec:
> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
>   This effectively allows setting MADV_HUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine, this will allow workloads that benefit from always having
>   hugepages to do so, without regressing those that don't.
> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
>   for the default VMA flags. It will also iterate through every VMA in the
>   process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
>   This effectively allows setting MADV_NOHUGEPAGE on the entire process.
>   In an environment where different types of workloads are run on the
>   same machine,this will allow workloads that benefit from having
>   hugepages on an madvise basis only to do so, without regressing those
>   that benefit from having hugepages always.
> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
>   VM_NOHUGEPAGE process for the default flags.
>
> In hyperscalers, we have a single THP policy for the entire fleet.
> We have different types of workloads (e.g. AI/compute/databases/etc)
> running on a single server.
> Some of these workloads will benefit from always getting THP at fault
> (or collapsed by khugepaged), some of them will benefit by only getting
> them at madvise.
>
> This series is useful for 2 usecases:
> 1) global system policy = madvise, while we want some workloads to get THPs
> at fault and by khugepaged :- some processes (e.g. AI workloads) benefits
> from getting THPs at fault (and collapsed by khugepaged). Other workloads
> like databases will incur regression (either a performance regression or
> they are completely memory bound and even a very slight increase in memory
> will cause them to OOM). So what these patches will do is allow setting
> prctl(PR_DEFAULT_MADV_HUGEPAGE) on the AI workloads, (This is how
> workloads are deployed in our (Meta's/Facebook) fleet at this moment).
>
> 2) global system policy = always, while we want some workloads to get THPs
> only on madvise basis :- Same reason as 1). What these patches
> will do is allow setting prctl(PR_DEFAULT_MADV_NOHUGEPAGE) on the database
> workloads. (We hope this is us (Meta) in the near future, if a majority of
> workloads show that they benefit from always, we flip the default host
> setting to "always" across the fleet and workloads that regress can opt-out
> and be "madvise". New services developed will then be tested with always by
> default. "always" is also the default defconfig option upstream, so I would
> imagine this is faced by others as well.)
>
> v2->v3: (Thanks Lorenzo for all the below feedback!)
> v2: https://lore.kernel.org/all/20250515133519.2779639-1-usamaarif642@gmail.com/
> - no more flags2.
> - no more MMF2_...
> - renamed policy to PR_DEFAULT_MADV_(NO)HUGEPAGE
> - mmap_write_lock_killable acquired in PR_GET_THP_POLICY
> - mmap_write lock fixed in PR_SET_THP_POLICY
> - mmap assert check in process_default_madv_hugepage
> - check if hugepage_global_enabled is enabled in the call and account for s390
> - set mm->def_flags VM_HUGEPAGE and VM_NOHUGEPAGE according to the policy in
>   the way done by madvise(). I believe VM merge will not be broken in
>   this way.
> - process_default_madv_hugepage function that does for_each_vma and calls
>   hugepage_madvise.
>
> v1->v2:
> - change from modifying the THP decision making for the process, to modifying
>   VMA flags only. This prevents further complicating the logic used to
>   determine THP order (Thanks David!)
> - change from using a prctl per policy change to just using PR_SET_THP_POLICY
>   and arg2 to set the policy. (Zi Yan)
> - Introduce PR_THP_POLICY_DEFAULT_NOHUGE and PR_THP_POLICY_DEFAULT_SYSTEM
> - Add selftests and documentation.
>
> Usama Arif (7):
>   mm: khugepaged: extract vm flag setting outside of hugepage_madvise
>   prctl: introduce PR_DEFAULT_MADV_HUGEPAGE for the process
>   prctl: introduce PR_DEFAULT_MADV_NOHUGEPAGE for the process
>   prctl: introduce PR_THP_POLICY_SYSTEM for the process
>   selftests: prctl: introduce tests for PR_DEFAULT_MADV_NOHUGEPAGE
>   selftests: prctl: introduce tests for PR_THP_POLICY_DEFAULT_HUGE
>   docs: transhuge: document process level THP controls
>
>  Documentation/admin-guide/mm/transhuge.rst    |  42 +++
>  include/linux/huge_mm.h                       |   2 +
>  include/linux/mm.h                            |   2 +-
>  include/linux/mm_types.h                      |   4 +-
>  include/uapi/linux/prctl.h                    |   6 +
>  kernel/sys.c                                  |  53 ++++
>  mm/huge_memory.c                              |  13 +
>  mm/khugepaged.c                               |  26 +-
>  tools/include/uapi/linux/prctl.h              |   6 +
>  .../trace/beauty/include/uapi/linux/prctl.h   |   6 +
>  tools/testing/selftests/prctl/Makefile        |   2 +-
>  tools/testing/selftests/prctl/thp_policy.c    | 286 ++++++++++++++++++
>  12 files changed, 436 insertions(+), 12 deletions(-)
>  create mode 100644 tools/testing/selftests/prctl/thp_policy.c
>
> --
> 2.47.1
>

On 20/05/2025 06:14, Lorenzo Stoakes wrote:
> NACK the whole series.
> 
> Usama - I explicitly said make this an RFC, so we can see what this
> approach _looks like_ to further examine it, to which you agreed. And now
> you've sent it non-RFC. That's not acceptable.
> 
> If you agree to something in review, it's not then optional as to whether
> you do it.

It was a bit late yesterday and I completely forgot to change --subject-prefix="PATCH v3" 
to --subject-prefix="RFC v3". Mistakes happen and I apologize.

I agreed to make it RFC and had full intention of doing that.
Would you like me to resend it with the RFC tag?

Thanks,
Usama

On Tue, May 20, 2025 at 08:46:43AM +0100, Usama Arif wrote:
>
>
> On 20/05/2025 06:14, Lorenzo Stoakes wrote:
> > NACK the whole series.
> >
> > Usama - I explicitly said make this an RFC, so we can see what this
> > approach _looks like_ to further examine it, to which you agreed. And now
> > you've sent it non-RFC. That's not acceptable.
> >
> > If you agree to something in review, it's not then optional as to whether
> > you do it.
>
> It was a bit late yesterday and I completely forgot to change --subject-prefix="PATCH v3"
> to --subject-prefix="RFC v3". Mistakes happen and I apologize.

Ack, but in future please try to be careful about this! This obviously
changes the nature of the series and important to highlight we're still in
the planning stages here.

>
> I agreed to make it RFC and had full intention of doing that.
> Would you like me to resend it with the RFC tag?

There's no need, we've got discussion here already so it's sensible to keep
things as-is, the series is in-effect an RFC now as it's NACK'd.

>
> Thanks,
> Usama

Cheers, Lorenzo