[PATCH] libcsupport: Have greedy allocations use consume extended memory

[Joel Sherrill]

On Mon, Feb 8, 2021 at 12:44 AM Chris Johns <chrisj at rtems.org> wrote:

> On 8/2/21 5:38 pm, Sebastian Huber wrote:
> >
> > On 08/02/2021 07:30, chrisj at rtems.org wrote:
> >> diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> index 4dda39873f..2361f17d2e 100644
> >> --- a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> +++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> @@ -30,8 +30,20 @@ void *rtems_heap_greedy_allocate(
> >>     size_t block_count
> >>   )
> >>   {
> >> +  Heap_Control *heap = RTEMS_Malloc_Heap;
> >> +  size_t size = 128 * 1024 * 1024;
> >>     void *opaque;
> >>   +  while (size > 0) {
> >> +    opaque = (*rtems_malloc_extend_handler)( heap, size );
> >> +    if (opaque == NULL) {
> >> +      size >>= 1;
> >> +    } else {
> >> +      if ( rtems_malloc_dirty_helper != NULL )
> >> +    (*rtems_malloc_dirty_helper)( opaque, size );
> >> +    }
> >> +  }
> > You need a couple of more ' ' after and before the braces. Each if
> should have a
> > { }. Apart from the formatting it looks good.
>
> Thanks, I will fix the formatting and push.
>
> And there is no performance issue on hardware so that must be a psim thing.
>

What performance issue do you think there could have been?

This must just be a side-effect of the PowerPC BSPs which have more than
32MB
RAM and want to support dynamically loading code. They must ensure that no
branches or calls exceed 32MB from the current location. Thus it has to be
loaded
early in program life before the heap is extended.

Are there other supported architectures where code must fit into a subset
of the
address space where it could negatively impact dynamic loading?

How does the DL code deal with PPC code that is built without the
-mlongcall
option?

EPICS discusses this here:

https://epics.anl.gov/base/ppc.php

--joel


> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210208/87a241dc/attachment.html>