Stack requirements, why is it so big?
joel.sherrill at OARcorp.com
Mon May 8 13:48:04 UTC 2000
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
+ If not using the In-Memory Filsystem for anything
except device names, then define
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
More information about the users