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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
