RFC: Initializing and placement of thread/fiber/task stacks


Mitsis, Peter <Peter.Mitsis@...>
 

Any objections/comments to the following?

Thread stacks (as defined by the __stack attribute) should be placed into their own section. By default this section should be a part of the .noinit section so that they do not impact run time performance. However, if the Kconfig option INIT_STACKS is enabled, then the stacks should be placed into their own unique section and their stack space should be initialized at boot time to a known value (0xaa).

Although this will result in a longer boot time (when INIT_STACKS) is enabled, it means that aside from the potential boot time penalty, there is never a stack initialization run time penalty when creating a thread. This may be particularly beneficial should a thread be restarted or thread-space be reused as the stack will not be re-initialized. Note that this changes the semantics of thread stack usage to mean thread stack usage for all threads that use that stack.

Peter Mitsis


Andy Ross
 

Mitsis, Peter wrote:
Thread stacks (as defined by the __stack attribute) should be placed
into their own section. By default this section should be a part of
the .noinit section so that they do not impact run time
performance. However, if the Kconfig option INIT_STACKS is enabled,
then the stacks should be placed into their own unique section and
their stack space should be initialized at boot time to a known
value (0xaa).
+1 from me at least. Nothing in any relevant platform standards I'm
aware of say anything about unused stack contents at thread start or
entry to main(), and programmers and compilers have generating robust
code in these stacks for decades. It's routine to throw malloc()
output at pthreads for a stack, for example.

Andy


Mitsis, Peter <Peter.Mitsis@...>
 

Apparently redefining '__stack' for both a thread's stack alignment and stack section placement will not work as we have many instances where those stacks are embedded within other structures.

Thus, I would like to modify the original proposal to the following:


1. Introduce a new tag (__stack_section) that will put thread stacks into the appropriate linker section. If CONFIG_INIT_STACKS is enabled, this stack section will be initialized to 0xaa's at boot time.

2. Rename the existing '__stack' tag to '__stack_align'. This is to make it clear that the tag is strictly for ensuring proper alignment, and that it does not become confused with '__stack_section'.

3. Update the thread initialization code to initialize its stack to 0xaa's only if ...

a. CONFIG_INIT_STACKS is enabled

b. AND the stack is not in the stack section (for when the stack is embedded in another structure).

Thoughts, comments, objections?

Peter Mitsis

From: Mitsis, Peter [mailto:Peter.Mitsis(a)windriver.com]
Sent: September-21-16 4:21 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Initializing and placement of thread/fiber/task stacks

Any objections/comments to the following?

Thread stacks (as defined by the __stack attribute) should be placed into their own section. By default this section should be a part of the .noinit section so that they do not impact run time performance. However, if the Kconfig option INIT_STACKS is enabled, then the stacks should be placed into their own unique section and their stack space should be initialized at boot time to a known value (0xaa).

Although this will result in a longer boot time (when INIT_STACKS) is enabled, it means that aside from the potential boot time penalty, there is never a stack initialization run time penalty when creating a thread. This may be particularly beneficial should a thread be restarted or thread-space be reused as the stack will not be re-initialized. Note that this changes the semantics of thread stack usage to mean thread stack usage for all threads that use that stack.

Peter Mitsis