Stack requirements, why is it so big?

[Joel Sherrill]

Ok.  Some more information and a hint as to some future
work that can be done to help things out further. :)

+ Using confdefs.h, if you do not specify the number
  of tasks/threads, then for each API you enable, the
  default number of tasks/threads for that API is 10.
  This results in 80K reserved for stack with just
  the Classic API enabled and a minimum stack of 10K.

  Solution:  When concerned about memory, specify the
  real number of tasks/threads you require.  If you enable
  posix but don't need posix threads, then the confdefs.h
  default adds a lot of memory.

+ Again using confdefs.h, the default number of file
  descriptors is 20.  This is probably too high for
  many applications.  The constant is
  CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS.  I think
  you need 3 for stdin, out, and error plus extras
  for sockets, in-memory files, and ttftp client
  opens.

+ If not using the In-Memory Filsystem for anything
  except device names, then define 
  CONFIGURE_USE_MINIIMFS_AS_BASE_FILESYSTEM.  This
  gives you a subset of the IMFS that is functionally
  comparable to the 4.0 filesystem functionality.

Try those and see how much it changes. :)

Most of confdefs.h constants default to 0 so don't
contribute to bloat.  confdefs.h is trying to strike
a balance between useful defaults and bloat. :)

Longer term fixes that have been kicked around
inside OAR and could be implemented given some
sponsorship <hint, hint out there :)>:

+ user configurable minimum stack size.  This would
  allow you to lower the 8K to whatever is really
  appropriate for your application.

+ Use stack established by BSP at system startup
  for IDLE task stack.  This would save a task stack.

+ Configurable maximum number of priorities between
  2 and 255.  The implementation of the ready chain
  is an array of Chains -- one per priority, allocated
  from the Workspace.

+ Ability to instantiate application specific 
  tailored version of the "initialize executive"
  sequence.  This would let you avoid even calling
  the initialization routine for managers you do
  not require in your application.  Thus you would
  not include their data or workspace allocations.

Between the things listed above and some others I did not
mention, the RAM footprint can drop considerably.

I don't think anyone has really mentioned it on the
list but I would like to see reports on code space
requirement changes since 4.0.  I think great strides
have been made there.  There were some dependencies
that had crept in that made applications pull in some
surprising code. :)

Leon Pollak wrote:
> 
> Hello, all.
>     My application has 16 tasks, which means that, using default
> STACK_MINIMUM_SIZE definition (which is 8K for powerpc cpu MPC860), I
> must have RTEMS workspace size >> 112K.
>     I can't use less because the 'thread create" process checks this and
> forces the default minimum size to be used.
>     Having the following numbers for code:
> librtems_g - 86K
> libcsupport - 14k
> libc    - 10k
> my application 110K
> my data - 145K
> 
>     this means that I have no memory in my 512K RAM. And all this before
> the networking, which I didn't incorporate yet (but for which I have
> another bank of 512K RAM).
> 
>     Now, in this connection, I have two questions:
> 1. What are the ideas behind this default definition of the stack to 8K?
> The old version of C Application Supplement for 68020 that I have says
> that 331 byte is enough. I wasn't able to find the corresponding
> document for powerpc. Does it exist?
> 2. If the figures I mentioned are approximately correct, how do the
> people use networking? How much RAM do you have?
> 
> I shall be very thankful for the clarification.
> 
> leonp at plris.com

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