test for rtems_workspace_greedy_allocate

[Chris Johns]

On 10/2/21 4:12 pm, Sebastian Huber wrote:
> On 09/02/2021 23:17, Chris Johns wrote:
> 
>> 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 ...
> 
> With unified work areas I mean this configuration option:
> 
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-unified-work-areas

Ah OK. I thought they used the single memory pool differently. If it is the same
heap and allocator then this is similar.

>> 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.
> For a real SMP system (note: symmetric), it doesn't matter at which physical
> address range your allocated memory is. However, the lager SMP systems are
> really NUMA systems with different memory controllers and some sort of on-chip
> network. For this you need a domain based memory allocator. FreeBSD has such an
> allocator: UMA.

I think this will become important.

Chris