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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
