[PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Sebastian Huber]

On 06/10/2022 00:13, Chris Johns wrote:
>>> In this patch you discuss applications with "very dynamic thread-local storage
>>> size"? I have no idea what this means and under what conditions such an app is
>>> created. Could you please explain this?
>> A scenario is a bigger organization in which one department deals with the basic
>> RTEMS and platform support and another department develops the application
>> (without knowing much about RTEMS). The platform is a 64-bit processor with lots
>> of RAM. The application is a high performance SMP development using modern
>> software frameworks which use TLS.
> If libdl is put aside, would the same mechanics used to size the TLS area for
> any score thread be the same for IDLE?

The only other score thread is the MPCI thread. I haven't looked at this 
one yet.

> 
>>>> * Adds a new option CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE which ensures that
>>>> the IDLE task stack size has at least this size.
>>> Can you please provide a use case for these variables showing what is being
>>> solved and when a user would need them?
>> With a statically allocated IDLE task storage area you need a lower bound for
>> the stack size. This is missing right now. Currently, if you have a TLS size
>> which is larger than CONFIGURE_IDLE_TASK_STACK_SIZE, then you have a memory
>> corruption during system initialization.
> Ah OK. Does this mean the static allocation cannot take into account the size of
> the static TLS area?

The static allocation needs to take the potential TLS area into account. 
However, the actual TLS area size could be larger than expected.

> 
>> With the new CONFIGURE_IDLE_TASK_STORAGE_SIZE option we could also use
>> CONFIGURE_IDLE_TASK_STACK_SIZE to ensure this minimum stack size. I will adjust
>> the next patch to not introduce CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE.
> OK
> 
>>> The IDLE stack size was used on architectures where the interrupt stack was on
>>> the executing task's stack. We have been able to move away from that model to
>>> having a separate interrupt stack. As a result the stack usage for IDLE is
>>> deterministic because the code makes no calls and is little more than a loop. As
>>> a result the default IDLE stack size should be OK for all users expect those
>>> adding their own IDLE thread?
>> There are some calls to reach the loop, for example the thread begin extensions
>> and the thread switch extensions.
> So this is a side effect of switching of newlib to TLS variables?

The use of TLS objects in Newlib makes this issue more visible.

> 
>> Next proposal:
>>
>>
>> * Change the default IDLE task storage allocation to the workspace.  It will use
>> CONFIGURE_IDLE_TASK_STACK_SIZE and this size will define the stack size.
>>
>> * Add a new option CONFIGURE_IDLE_TASK_STORAGE_SIZE which will change the IDLE
>> task storage allocation to a statically allocated area which will contain the
>> task stack and the thread-local storage area.
>>
>> * Use CONFIGURE_IDLE_TASK_STACK_SIZE which ensures that the IDLE task stack size
>> has at least this size in case the statically allocated area is used.
>>
>> With this change you don't have to worry about the TLS size in the default
>> configuration. If you enable the static allocation, then you don't get undefined
>> behaviour if your actual TLS size exceeds the configured limits.
> Sounds good. Thanks for taking the time to explain the change.
> 
> Will the IDLE TLS size be based on the
> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
> libdl once it supports loading TLS based code.

Currently, only the actual TLS size is used. We would have to change 
_TLS_Get_allocation_size() to use the maximum if it is non-zero.

> 
> [ while looking at the doco ... ]
> 
> Should CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE be under General System
> Configuration because it applies to all threads?

Makes sense, I moved the option.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/