test for rtems_workspace_greedy_allocate

[Chris Johns]

On 10/2/21 1:10 am, Sebastian Huber wrote:
> On 09/02/2021 14:59, Gedare Bloom wrote:
> 
>>> sbrk() cannot be removed and we need to maintained and test it as a BSP level
>>> interface.
>>>
>>> This is an nice design idea where the sbrk() pool of memory can be given out to
>>> the heap or workspace depending on the demands of the application. I can see
>>> this being important to application frameworks like EPICS and so something we
>>> should look to add to all architectures.
>>>
>>   Please raise a ticket, this can be a GSoC project idea I think?
> What is the benefit of sbrk() compared to the unified work areas? Do address
> fragmentation/performance issues it makes more sense to replace the first fit
> allocator with something else.

Good question. A couple of points come to mind ...

A unified workspace has the workspace and heap at different ends of the memory
gowing towards each other while sbrk has the blocks in closer proximity and
interleaved. Would there be performance differences with caches and SMP? For
example creating tasks each with some dynamic memory.

The unified address space requires memory be continuous and sbrk() does not.

Chris