Re: [PATCH] Created tunable to force small pages on stack allocation.

[Cupertino Miranda <cupertino.miranda@oracle.com>]

Adhemerval Zanella Netto writes:

> On 13/03/23 07:07, Cupertino Miranda wrote:
>>
>> Hi Florian
>>
>>> * Cupertino Miranda via Libc-alpha:
>>>
>>>> +static void
>>>> +TUNABLE_CALLBACK (set_stack_hugetlb) (tunable_val_t *valp)
>>>> +{
>>>> +  enum malloc_thp_mode_t thp_mode = __malloc_thp_mode ();
>>>> +  /*
>>>> +     Only allow to change the default of this tunable if the system
>>>> +     does support and has either 'madvise' or 'always' mode. Otherwise
>>>> +     the madvise() call is wasteful.
>>>> +  */
>>>> +  switch(thp_mode)
>>>> +    {
>>>> +    case malloc_thp_mode_always:
>>>> +    case malloc_thp_mode_madvise:
>>>> +      __nptl_stack_hugetlb = (int32_t) valp->numval;
>>>> +      break;
>>>> +    default:
>>>> +      break;
>>>> +    }
>>>> +}
>>>
>>> I suspect that quite a few failing madvise calls are cheaper than the
>>> those three system calls in __malloc_thp_mode.  In addition,
>>> __malloc_thp_mode may fail due to future kernel changes, disabling the
>>> tunable by accident.
>> Thanks for your review. Ok, I did not check the inner workings of
>> malloc_thp_mode. I used it by suggestion from the RFC thread.
>> I will prepare a version removing it.
>
> It only make sense to madvise iff __malloc_thp_mode is set as 'always',
> and tunable is a opt-in feature.  So I think it would make sense to
> check the sysfs is tunable is used; the startup code will be amortized
> on high threads workloads.

From my side either solution is Ok. Using the __malloc_thp_mode would
protect the code from calls to madvise in systems that do not have
hugetlb support. This would avoid returning an error on madvise if the
advice argument is not identified as valid.