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