Re: [PATCH v3 0/7] prctl: introduce PR_SET/GET_THP_POLICY

[Usama Arif <usamaarif642@gmail.com>]

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