[PATCH 1/3] score: Remove _Stack_Adjust_size()

Gedare Bloom gedare at rtems.org
Sun Apr 15 18:05:31 UTC 2012


Where did the original stack size adjustment come from / what was its
motivation?  Will this break something that was "fixed" by the
previous approach?

FWIW I view the stack adjustment as it was done previously to be a
hack and the elimination to be a good thing.

On Thu, Apr 12, 2012 at 3:32 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 04/11/2012 11:53 AM, sebastian.huber at embedded-brains.de wrote:
>>
>> From: Sebastian Huber<sebastian.huber at embedded-brains.de>
>>
>> The increase of the stack size by CPU_STACK_ALIGNMENT in
>> _Thread_Stack_Allocate() is disadvantageous.  This may lead to a huge
>> over allocation for specialized stack allocators.  The
>> CPU_STACK_ALIGNMENT is at most 16 on all current RTEMS CPU ports.  The
>> mimimum stack size ensured by _Stack_Ensure_minimum() must be
>> considerable larger than this value, otherwise stack overflows will
>> likely occur.  Thus the _Stack_Adjust_size() is also superfluous.
>
>
> I would like to have your comments on this.  The background is that I have a
> special task stack allocator that has a page size of 4k due to some MMU/MPU
> constraints.  Thus if I request a stack size of 4k, this
> _Stack_Adjust_size() adjusts it to 4k + 4 which results in 8k allocated.
>  Quite a waste of memory.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> Phone   : +49 89 18 90 80 79-6
> Fax     : +49 89 18 90 80 79-9
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel




More information about the devel mailing list