memory overhead of rtems regions

Matthew J Fletcher amimjf at gmail.com
Thu Mar 7 16:44:21 UTC 2013


Gedare,

Thanks for the advice, for this particular region that's the optimal size,
I've done a bit of experimentation and you can find an optimal size for
most allocations.
 On 7 Mar 2013 14:38, "Gedare Bloom" <gedare at rtems.org> wrote:

> Looking closer, your allocations are multiples of 40. You should set
> the page_size to 40 in your region create.
>
> On Thu, Mar 7, 2013 at 9:37 AM, Gedare Bloom <gedare at rtems.org> wrote:
> > You're right. The error return does indicate that memory ran out. It's
> > not clear if the memory that ran out is heap or workspace.
> >
> > You set a page_size of 128, and then make allocations in multiples of
> > 10. I think the segments that get returned are allocated as multiples
> > of the page_size. So there will be some fragmentation issues. E.g. a
> > request for a segment of size 400 will return a 512 size segment,
> > wasting 112 bytes. This is stated in the C User Manual section about
> > Regions [1]. This fragmentation is probably causing the problem.
> >
> > -Gedare
> >
> > [1]
> http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/Region-Manager-Region-Manager-Definitions.html#Region-Manager-Region-Manager-Definitions
> >
> > On Thu, Mar 7, 2013 at 9:21 AM, Matthew J Fletcher <amimjf at gmail.com>
> wrote:
> >> Hi,
> >>
> >> Its 20, but I believe that would return RTEMS_TO_MANY, if that was not
> >> enough.
> >>
> >> On 7 Mar 2013 14:09, "Gedare Bloom" <gedare at rtems.org> wrote:
> >>>
> >>> Check how many message queues your application has configured.
> >>>
> >>> #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES    ?
> >>>
> >>> On Thu, Mar 7, 2013 at 7:05 AM, Matthew J Fletcher <amimjf at gmail.com>
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > Reading the documentation for rtems regions is a bit vague about the
> >>> > overhead of the lists that behind the scenes manage the blocks. Its
> >>> > quite
> >>> > possible i am not fully understanding the operation. I have a call
> >>> > sequence
> >>> > as follows.
> >>> >
> >>> > rtems_region_create( length = 19800, page_size = 128 )
> >>> >   rtems_region_get_segment( size = 160 )
> >>> >     rtems_message_queue_create ( count = 160, max_size =2 )
> >>> >   rtems_region_get_segment( size = 400 )
> >>> >     rtems_message_queue_create ( count = 400, max_size =2 )
> >>> >   rtems_region_get_segment( size = 1600 )
> >>> >     rtems_message_queue_create ( count = 1600, max_size =2 )
> >>> >   rtems_region_get_segment( size = 40 )
> >>> >     rtems_message_queue_create ( count = 40, max_size =2 )
> >>> >   rtems_region_get_segment( size = 4000 )
> >>> >     rtems_message_queue_create ( count = 4000, max_size =2 )
> >>> >   rtems_region_get_segment( size = 40 )
> >>> >     rtems_message_queue_create ( count = 40, max_size =2 )
> >>> >   rtems_region_get_segment( size = 40 )
> >>> >     rtems_message_queue_create ( count = 40, max_size =2 )
> >>> >   rtems_region_get_segment( size = 40 )
> >>> >     rtems_message_queue_create ( count = 40, max_size =2 )
> >>> >   rtems_region_get_segment( size = 40 )
> >>> >     rtems_message_queue_create ( count = 40, max_size =2 )
> >>> >   rtems_region_get_segment( size = 120 )
> >>> >     rtems_message_queue_create ( count = 120, max_size =2 )
> >>> >   rtems_region_get_segment( size = 400 )
> >>> >     rtems_message_queue_create ( count = 400, max_size =2 )
> >>> >   rtems_region_get_segment( size = 400 )
> >>> >     rtems_message_queue_create ( count = 400, max_size =2 )
> >>> >   rtems_region_get_segment( size = 2000 ) // total size upto here
> 7320
> >>> >     rtems_message_queue_create ( count = 2000, max_size =2 )
> >>> >     // returns RTEMS_UNSATISFIED - unable to allocate message buffers
> >>> > here
> >>> >
> >>> > I dont fully understand why RTEMS_UNSATISFIED is being returned from
> the
> >>> > queue_create(), is there really a 50%+ overhead in managing 128 byte
> >>> > pages ?
> >>> > out of a 19800 length.
> >>> >
> >>> > I am presuming that the RTEMS_UNSATISFIED is because of the region
> size,
> >>> > but
> >>> > i could be wrong about that.
> >>> >
> >>> >
> >>> > regards
> >>> > ---
> >>> > Matthew J Fletcher
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > rtems-users mailing list
> >>> > rtems-users at rtems.org
> >>> > http://www.rtems.org/mailman/listinfo/rtems-users
> >>> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130307/8152d2b8/attachment.html>


More information about the users mailing list