Region manager memory allocation
joel.sherrill at OARcorp.com
Tue Jan 4 13:42:13 UTC 2000
Nick.SIMON at syntegra.bt.co.uk wrote:
> 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
> 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.
it is 4 or 8 byte boundaries.
8 is required on some architectures since malloc'ed items must be
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
is just testing that a large page size works.
Other approaches which have been discussed (not implemented) in the past
+ adding another type of memory allocation scheme which keeps the
information separate from the memory itself (allocate via bitmap or
+ switch to using the semaphore protected malloc implementation in
newlibs. I don't recall whether this was available in 1.8.1 but I
sure this is available in 1.8.2.
There are only two heaps/regions used in most RTEMS systems -- executive
and the program heap (malloc). Those have very small page sizes -- 4 or
> -- 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
More information about the users