On 21/05/2025 03:33, Liam R. Howlett wrote:
> * Usama Arif <usamaarif642@xxxxxxxxx> [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
