RTEMS Workspsace number of used blocks?

[Joel Sherrill]

On 08/17/2010 09:37 AM, Peter Dufault wrote:
> (BSP is phycore_mpc5554 based on mpc55xxevb running 4.10)
>
> I think my workspace must be misconfigured.  I had a long-running test crash on me and I got this from the monitor "wkspace" command:
>
> C Program Heap and RTEMS Workspace are separate.
> Number of free blocks: 1
> Largest free block:    352720
> Total bytes free:      352720
> Number of used blocks: 99
> Largest used block:    131096
> Total bytes used:      433824
>
> There is "1 free block" left and it is big, with 99 in use.  I assume the number of blocks is fixed at 100, and I should have done something to balance the total free area and the number of blocks.
>
>    
No.  The 99 means there have been 99 allocations from the workspace.
> I see there is a unified work area option.  Am I better off enabling CONFIGURE_UNIFIED_WORK_AREAS?
>
>    
This is more desirable if you want to run unlimited objects.  I think 
you have
simply set your maximum's to more than you have created at this point.  
If you
have hard limits in your application and you know them, I see no point 
in unlimited.
> I also see some comments about "unlimited objects" in cpukit/sapi/include/confdefs.h.  What does this do?
>
>    
It allows you to create instances of objects (e.g. tasks, semaphore, etc)
until you run out of memory. It takes away the hard limit on that particular
class of objects and turns the "maximum" into an "allocation unit".  So
configure 10 tasks unlimited and when you created number 11, it will
pre-allocate 11-20.

The idea of unlimited is at odds with having a small RTEMS Workspace
separate from the larger malloc heap space.   When doing unlimited, you
want the largest pool of memory possible.
> Is there a recent outline of the configurable options?
>
>    
The Configuring a System chapter in the user's guide.  I don't know that
it really discusses the trade-offs in unlimited and unified work space.
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985