Region manager memory allocation

[Nick.SIMON at syntegra.bt.co.uk]

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. 

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?


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.

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