CONFIGURE_MINIMUM_TASK_STACK_SIZE

[Gedare Bloom]

On Wed, Dec 7, 2011 at 4:52 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> On 12/07/2011 03:48 PM, Chris Johns wrote:
>>
>> On 8/12/11 5:39 AM, Gedare Bloom wrote:
>>>
>>> CONFIGURE_MINIMUM_TASK_STACK_SIZE can be defined by an application to
>>> increase the size of all of its task stacks (and implicitly the init
>>> task and interrupt stacks). It seems wrong/wasteful to propagate the
>>> user-defined CONFIGURE_MINIMUM_TASK_STACK_SIZE to both the idle and
>>> interrupt stacks, perhaps these should be CPU_STACK_MINIMUM_SIZE
>>> unless defined by the user explicitly?
>>>
>> What does a minimum stack size mean ?
>>
>> I have always assumed this setting provides enough stack so the tests
>> could run across a number of platforms. I do not use it in any
>> applications I develop.
>
> It is more of a "enough to run hello" type of definition.  If you
> have less than this, then you are likely in trouble. Many tests
> do 2-3 times minimum for their task stacks.
>
My concern is that this one configure macro propagates into other
macros that need not be so dependent.  The valid use of it is that it
gets assigned into rtems_minimum_stack_size which is used when a task
is created to ensure the requested stack size meets this minimum.

One problem I see is that when a user creates tasks if they specify
RTEMS_MINIMUM_STACK_SIZE as the stack size parameter, then they are
actually asking for the CPU_STACK_MINIMUM_SIZE and we currently ignore
the CONFIGURE_MINIMUM_TASK_STACK_SIZE for such request.

I have used CONFIGURE_EXTRA_TASK_STACKS when I have tasks that need an
oversized stack, and then I will pass the stack size explicitly. All
this macro does is to ensure the workspace has enough space for what I
plan to request, and does not affect any other stack calculations
(like idle, init, or interrupt stack size).

>> Yes it would seem to be wasteful for idle. The init task is tricky
>> because static constructors run on it.
>
> Nope. Static constructors run in the first init task.
>
Well, I don't see how the constructors are accounted for.

>> If you use the BSP init code in
>> bsp/shared where your entry point is main the network stack maybe
>> started. There is also the implicit stack in the BSP context that starts
>> RTEMS. These all require the user's involvement to make sure they are
>> big enough.
>
> The stack the BSP starts on is very special and has to be
> established outside RTEMS.  We can't do much about that
> at this level.
>
> With that said, many BSPs specify where this stack is in
> the linker script and have a variable like StackSize that
> you can -D on the ld command to increase.
>
Yes we can ignore the BSP boot stack.

> Your network example would impact the init task.
>>
>>
>> Chris
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>
>