Region manager memory allocation

[Joel Sherrill]

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