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
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
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
