Re: [PATCH v2 3/4] elf: Avoid RELATIVE relocs in __tunables_init

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 08/01/2021 15:22, Siddhesh Poyarekar wrote:
> On 1/8/21 11:29 PM, Adhemerval Zanella via Libc-alpha wrote:
>>> @@ -38,7 +38,7 @@ __tunables_init (char **unused __attribute__ ((unused)))
>>>   /* A tunable.  */
>>>   struct _tunable
>>>   {
>>> -  const char *name;            /* Internal name of the tunable.  */
>>> +  const char name[64];            /* Internal name of the tunable.  */
>>>     tunable_type_t type;            /* Data type of the tunable.  */
>>>     tunable_val_t val;            /* The value.  */
>>>     bool initialized;            /* Flag to indicate that the tunable is
>>> @@ -54,7 +54,7 @@ struct _tunable
>>>                          target module if the value is
>>>                          considered unsafe.  */
>>>     /* Compatibility elements.  */
>>> -  const char *env_alias;        /* The compatibility environment
>>> +  const char env_alias[24];        /* The compatibility environment
>>>                          variable name.  */
>>>   };
>>>   
> <snip>
>> The change is ok, although I think we can at least not make the maximum r
>> equired size being automatically generated at build time:
> 
> I don't have a strong preference either way, but the nice thing about the above hardcoded sizes is that it makes the struct size 128 bytes, which means that the array lines up nicely with each element in a pair of cachelines on 64-bit architectures.
> 
> The code is not performance sensitive, so it's probably just an asthaetic thing :)

The struct is maked as read-only, so I doubt we will need to optimize
for cacheline to avoid false-sharing.  And coupling the size with the
tunable definitions itself is one less required change if tunables are
modified.