Region manager memory allocation

[Ryan Bedwell]

Gentlemen,

Thanks for the discussion.  Reducing the page size does solve the
"problem."  Perhaps this should be noted in the test's (sp16) docs?

Thanks again,

Ryan

Joel Sherrill wrote:
> 
> Nick.SIMON at syntegra.bt.co.uk wrote:
> >
> > Ryan,
> >
> > Looking at the code a little further down _Heap_Allocate in heap.c, it seems
> > that the allocated pointer is expected to be on a page boundary (& if so,
> > the documentation's not quite right).  This means that more memory has to be
> > allocated than might appear necessary.  Having said this, however, the
> > consumed size should always be a multiple of page size, which it obviously
> > isn't - your figures show HEAP_BLOCK_USED_OVERHEAD too much has been
> > allocated. Presumably, the blocks get misaligned off the page boundaries
> > too.
> >
> > BTW It looks as if the boundary alignment was a later addition.  Does anyone
> > know why it was added?  It does make sizing etc much more awkward, and the
> > oversizing may be an attempt to make it easier to decide if a free block is
> > big enough.
> 
> I don't recall it being a later addition.  But that was a long time ago.
> :)
> 
> > Having said all that, much more saving would be made by reducing page_size.
> > Since RTEMS doesn't use VM, protection & all that stuff, is there any need
> > for page_size to be so big?
> 
> The code in question is simply a test.  I thought all the ports set the
> page_size to default to 16 or less for the region used by malloc.
> Usually
> it is 4 or 8 byte boundaries.
> 
> 8 is required on some architectures since malloc'ed  items must be
> aligned
> well enough to be doubles.
> 
> > Memory allocation is a bit too important to be (apparently) messed up.  If
> > anyone can shed light on this, this, please let us all know.
> 
> Repeating myself, the code in question is simply a test.  The large page
> size
> is just testing that a large page size works.
> 
> Other approaches which have been discussed (not implemented) in the past
> include:
> 
>   + adding another type of memory allocation scheme which keeps the
> allocation
>     information separate from the memory itself (allocate via bitmap or
> something).
>   + switch to using the semaphore protected malloc implementation in
> late model
>     newlibs.  I don't recall whether this was available in 1.8.1 but I
> am pretty
>     sure this is available in 1.8.2.
> 
> There are only two heaps/regions used in most RTEMS systems -- executive
> workspace
> and the program heap (malloc).  Those have very small page sizes -- 4 or
> 8.
> 
> > -- Nick Simon
> >
> > > -----Original Message-----
> > > From: Ryan Bedwell [mailto:ra9407 at email.sps.mot.com]
> > > Sent: 23 December 1999 16:16
> > > To: rtems-list at oarcorp.com
> > > Subject: Region manager memory allocation
> > >
> > >
> > > All,
> > >
> > > I'm trying to track down a bug I've got in my new BSP with region
> > > manager memory allocation.  According to the docs, when a block of
> > > memory is requested from the region manager, that number will
> > > be rounded
> > > up to the nearest page size and allocated (if enough memory is free):
> > >
> > > <snip>
> > >
> > > "For example, if a request for a 350-byte segment is made in a region
> > > with 256-byte pages, then a 512-byte segment is allocated."
> > >
> > > </snip>
> > >
> > > However, I'm seeing much larger segments being allocated.
> > > Here's a snip
> > > from a little loop that I wrote.  The example uses 128 byte pages and
> > > obtains the actual sizes via calls to rtems_region_get_segment_size():
> > >
> > > Request: 64, Grant: 264
> > > Request: 128, Grant: 264
> > > Request: 192, Grant: 392
> > > Request: 256, Grant: 392
> > > Request: 320, Grant: 520
> > > Request: 384, Grant: 520
> > > Request: 448, Grant: 648
> > > Request: 512, Grant: 648
> > > Request: 576, Grant: 776
> > >
> > > These numbers seem to make sense with the function _Heap_Allocate (in
> > > heap.c) where the actual work is done ('size' is the requested size):
> > >
> > > <snip>
> > >
> > >   excess   = size % the_heap->page_size;
> > >   the_size = size + the_heap->page_size + HEAP_BLOCK_USED_OVERHEAD;
> > >
> > >   if ( excess )
> > >     the_size += the_heap->page_size - excess;
> > >
> > >   if ( the_size < sizeof( Heap_Block ) )
> > >     the_size = sizeof( Heap_Block );
> > >
> > > </snip>
> > >
> > > HEAP_BLOCK_USED_OVERHEAD is 8 bytes on my architecture, so this code
> > > would indicate that for a request of 64,
> > >
> > > excess = 64
> > > the_size = 64 + 128 + 8 = 200
> > > the_size += (128 - 64) = 264(!)
> > >
> > > What originally clued me in was a problem with test SP16; when an
> > > attempt is made to allocate 3968 bytes from a region that is
> > > 4096 bytes
> > > in length, there is never enough memory to satisfy the request!
> > >
> > > Can anyone enlighten?
> > >
> > > Thanks,
> > > Ryan
> > >
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985