minimum stack size was Re: #define delay(...)

Sergei Organov osv at javad.ru
Mon Nov 13 10:16:30 UTC 2000


Joel Sherrill <joel.sherrill at oarcorp.com> writes:
> Sergei Organov wrote:
> > 
> 
> > > This name is a relic from the very EARLIEST days of RTEMS.
> > 
> > "EARLIEST days of RTEMS" recalled me that I've had another suggestion for
> > RTEMS. What if in addition to one lower stack size limit
> > RTEMS_MINIMUM_STACK_SIZE we introduce another constant,
> > let's say, RTEMS_ABSOLUTE_MINIMUM_STACK_SIZE that will be indeed close to
> > absolute minimum for given architecture. All the test programs (as well as
> > applications) then will continue to use the former constant, but RTEMS core
> > will check input stack size by comparing it to the latter constant.
> > 
> > The problem with current approach is that the constant is actually too large
> > (e.g., 8K on PowerPC) and as RTEMS core doesn't allow to create tasks with
> > smaller stacks, light-weight tasks take too much memory for stack. Using my
> > suggestion ABSOLUTE_MINIMUM will be somewhere around 1K for PowerPC thus
> > saving 7K for every light-weight task. Or did situation change in this area
> > since RTEMS-3.6?
> 
> Hasn't changed but it has irritated me and I have something in mind.
> 
> What about minimum stack size defaulting to the current
> RTEMS_MINIMUM_STACK_SIZE
> value and the user being able to specify their own default size as an
> override.  What do you think of this?

I'd prefer different design, sorry. IMHO, the actual problem is that there are
actually two (or even three) different levels of minimum stack size:

1. Minimum stack size. Its value should be as small as possible for given
   architecture/calling conventions, i.e. it should be small enough to allow
   only very simple tasks (that don't require stack for its own purposes) to
   run.

2. Typical stack size. Minimum stack size +, let's say, ~10 stack frames for
   function calls.

3. Minimum stack size for all the tests to run, i.e. maximum(!) of stack
   requirements of all the tests. Surprisingly enough it's what
   RTEMS_MINIMUM_STACK_SIZE currently means!

I believe that attempts to model this with single constant will fail one way
or another.

If design it from scratch, I'd define RTEMS_MINIMUM_STACK_SIZE to (1),
RTEMS_TYPICAL_STACK_SIZE to (2), defaulted RTEMS_TEST_STACK_SIZE to
RTEMS_TYPICAL_STACK_SIZE, and let tests with greater stack requirements
redefine the RTEMS_TEST_STACK_SIZE. However, some user code could depend on
current meaning of RTEMS_MINIMUM_STACK_SIZE, so I suggested to don't change
its meaning and invent RTEMS_ABSOLUTE_MINIMUM_STACK_SIZE instead.

BR,
Sergei Organov.




More information about the users mailing list