[PATCH] malloc: Count tcache entries downwards

[Adhemerval Zanella Netto]

On 07/05/25 08:42, Florian Weimer wrote:
> * DJ Delorie:
> 
>> Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
>>> @@ -3337,6 +3337,8 @@ tcache_init(void)
>>>      {
>>>        tcache = (tcache_perthread_struct *) victim;
>>>        memset (tcache, 0, sizeof (tcache_perthread_struct));
>>> +      for (int i = 0; i < TCACHE_MAX_BINS; i++)
>>> +	tcache->counts[i] = mp_.tcache_count;
>>>      }
>>>  }
>>
>> In theory, the tunables can be changed at any time.  The existing code
>> happens to work with this, at the expense of a global read.  We need to
>> decide if we want to continue supporting that or if tunables are a
>> set-once-at-startup forever.  I have a pending patch set that makes
>> tunables more dynamic and may need this support, not that I'm biased ;-)
> 
> We currently do not have a way to change tunables at run time, and
> it's not safe in general.  If this were to change and we want this to
> be effective for malloc tunables, we'd have to write extra code with
> special synchronization either way.  So I don't think Wilco's change
> makes things much harder.

The tunable_list is currently marked as attribute_relro and I think the
current idea of the tunable framework is to have set-once-at-startup.  It
means the user knows which parameters was set so it can know which kind
of performance, security, or any other values are used and expected during
program execution.

Besides the synchronization issues, there is also possible security
implications if we start to make the tunable_list no rdonly during
process execution (since we use to enable PAC, memory tagging, and now
GCS support). We will need to at least split between two list, which
will adds more complexity.

So I think for malloc we should keep using the tunables as rdonly and
set-once-at-startup  and add extra internal variables to have this
dynamic mechanism. What kind of support are envisioning that requires
dynamic tunables?