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

[Chris Johns]

On 9/2/21 8:09 am, Joel Sherrill wrote:
> 
> 
> On Mon, Feb 8, 2021, 3:00 PM Chris Johns <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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>
>     <mailto: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. 

I am aware of this.

> 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.

I am sorry I am lost. This is related to extending the heap to use all memory
when testing env error codes. I have not seen a performance issue on real
hardware. When run on psim under gdb I saw some time being taken up in the
static call _Heap_Free_Block. The code looks linear to me so I moved on ...

https://git.rtems.org/rtems/tree/cpukit/score/src/heapextend.c#n27

I did not check if _Heap_Protection_free_all_delayed_blocks is looping on psim
and not in real hardware. I did not think this was likely, it would loop on both.

Chris