[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