test for rtems_workspace_greedy_allocate
sebastian.huber at embedded-brains.de
Wed Feb 10 05:12:57 UTC 2021
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
>>>> 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:
> 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.
> The unified address space requires memory be continuous and sbrk() does not.
embedded brains GmbH
Herr Sebastian HUBER
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
More information about the devel