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

Joel Sherrill joel at rtems.org
Mon Feb 8 21:09:56 UTC 2021


On Mon, Feb 8, 2021, 3:00 PM Chris Johns <chrisj at rtems.org> wrote:

> On 9/2/21 12:37 am, Joel Sherrill wrote:
> > On Mon, Feb 8, 2021 at 12:44 AM Chris Johns <chrisj at rtems.org
> > <mailto: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 <mailto: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?
>
> I do not know. I have never looked at how psim is implemented. I believe
> the
> slow down inside the simulator.
>
> > 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.
>
> This is inside the simulator?
>

No. This is BSP behavior for a number of the PowerPC BSPs.

If less than 32mb or no one ever used dynamic loading on it, then it
doesn't have sbrk support. And since dynamic loading was only available
with Till's cexp until you added dynamic loading, this tends to only show
up in bsps which are used with EPICS.


> > Are there other supported architectures where code must fit into a
> subset of the
> > address space where it could negatively impact dynamic loading?
>
> ARM.
>
> > How does the DL code deal with PPC code that is built without the
> -mlongcall
> > option?
>
> libdl adds a trampoline ...
>
> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-mdreloc-powerpc.c#n184
>
> Chris
>
> > EPICS discusses this here:
> >
> > https://epics.anl.gov/base/ppc.php <https://epics.anl.gov/base/ppc.php>
> >
> > --joel
> >
> >
> >     Chris
> >     _______________________________________________
> >     devel mailing list
> >     devel at rtems.org <mailto:devel at rtems.org>
> >     http://lists.rtems.org/mailman/listinfo/devel
> >     <http://lists.rtems.org/mailman/listinfo/devel>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210208/28b2f9bf/attachment.html>


More information about the devel mailing list