Re: RTEMS stack sizes

[Eric Norum <norume@aps.anl.gov>]

Would it make sense to provide an environment variable  
(EPICS_THREAD_STACK_SIZE_MULTIPLIER?)  or several such variables  
(EPICS_THREAD_STACK_SIZE_SMALL, _MEDIUM, _LARGE) to allow the default  
values to be overridden?
On Jan 22, 2009, at 9:48 AM, Kate Feng wrote:

> Eric Norum wrote:
> > Right -- a huge FLNK chain will eat up lots of stack.  We found  
> > this when we tried to FLNK 128 records....
> > I'm trying to find a size that's "good enough" for reasonable  
> > cases.  The current RTEMS sizes are about the same as those of  
> > vXWorks non-68k architecture machines and about twice that of  
> > vxWorks 68k machines.
> It is a good idea to find a size that's "good enough" for default.   
> It would be nice
> that those size could be custom defined at the
> configure/os/CONFIG.Common.RTEMS-bsp for various needs of
> applications.
>
> Kate
>
> > On Jan 22, 2009, at 9:23 AM, Jeff Hill wrote:
> >
> > > Note that the CAS-client thread calls db_put_field, and as I  
> > > recall the
> > > stack usage by db_put_field is dependent on the longest chain of  
> > > records
> > > that might be manipulated in the database (due to the recursive
> > > implementation of the database).
> > >
> > > > -----Original Message-----
> > > > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov 
> > > > ]
> > > > On Behalf Of Eric Norum
> > > > Sent: Wednesday, January 21, 2009 8:01 PM
> > > > To: tech-talk Techtalk
> > > > Subject: RTEMS stack sizes
> > > >
> > > > I'd like to solicit information from the EPICS community on the  
> > > > stack
> > > > allocation for RTEMS IOCs.  Please check the stack usage of some of
> > > > your RTEMS IOCs and send me the results.   I would like to find  
> > > > out if
> > > > it is possible and desirable to reduce the stack sizes to reduce  
> > > > the
> > > > memory footprint for each client.
> > > >
> > > > Here's the stack usage for one of the IOCs here (a ColdFire uCDIMM
> > > > 5282):
> > > >
> > > >   PID   PRI STATE   %CPU %STK  NAME
> > > > 09010001 255 READY   35.8    0  IDLE
> > > > 0a01004c 180 READY   10.6   18  CAS-event
> > > > 0a01001c 134 Wmutex   9.7   23  scan0.2
> > > > 0a010004  10 Wevnt    6.0   19  ntwk
> > > > 0a010006  10 Wevnt    6.0   22  FECr
> > > > 0a01005b 180 READY    4.2   18  CAS-event
> > > > 0a010044 180 READY    3.5   19  CAS-event
> > > > 0a010071 180 READY    3.5   19  CAS-event
> > > > 0a010005  10 Wevnt    3.2   22  FECt
> > > > 0a010031 179 READY    3.1   19  save_restore
> > > > 0a010020 183 READY    3.0   22  CAS-UDP
> > > > 0a01001a 136 Wmutex   2.2   23  scan1
> > > > 0a010019 137 Wmutex   1.5   23  scan2
> > > > 0a01003f 180 READY    1.3   16  CAS-event
> > > > 0a010021 180 READY    1.2   18  CAS-event
> > > > 0a010007  10 Wevnt    0.9   22  RPCd
> > > > 0a01002e 179 READY    0.7   20  CAS-client
> > > > 0a01006a 179 READY    0.7   20  CAS-client
> > > > 0a01002c 179 Wevnt    0.4   20  CAS-client
> > > > 0a010048 179 Wevnt    0.3   20  CAS-client
> > > > 0a010018 138 Wmutex   0.3   23  scan5
> > > > 0a010042 179 Wevnt    0.3   20  CAS-client
> > > > 0a01004e 179 Wevnt    0.1   20  CAS-client
> > > > 0a01001d 133 Wmutex   0.1   24  scan0.1
> > > > 0a010053 180 READY    0.0   19  CAS-event
> > > > 0a01000d 149 Wmutex   0.0   20  L0
> > > > 0a01001b 135 Wmutex   0.0   24  scan0.5
> > > > 0a010011 129 Wmutex   0.0   23  timerQueue
> > > > 0a010073 180 READY    0.0   19  CAS-event
> > > > 0a01002b 179 Wevnt    0.0   20  CAS-client
> > > > 0a010012 140 Wmutex   0.0   23  cbLow
> > > > 0a010017 139 Wmutex   0.0   20  scan10
> > > > 0a01005c 108 READY    0.0   16  SPY
> > > > 0a01000e 109 Wevnt    0.0   17  timeBroadcastMonitor
> > > > 0a010027 148 DELAY    0.0   23  seqAux
> > > > 0a010067 180 Wmutex   0.0   24  CAS-event
> > > > 0a010065 180 Wmutex   0.0   24  CAS-event
> > > > 0a010066 179 Wevnt    0.0   23  CAS-client
> > > > 0a01005f 180 Wmutex   0.0   19  CAS-event
> > > > 0a010062 179 Wevnt    0.0   20  CAS-client
> > > > 0a010078 179 Wevnt    0.0   23  CAS-client
> > > > 0a010076 179 Wevnt    0.0   23  CAS-client
> > > > 0a010074 179 Wevnt    0.0   20  CAS-client
> > > > 0a01006d 180 Wmutex   0.0   19  CAS-event
> > > > 0a010057 180 Wmutex   0.0   24  CAS-event
> > > > 0a010043 179 Wevnt    0.0   23  CAS-client
> > > > 0a01004b 179 Wevnt    0.0   20  CAS-client
> > > > 0a010054 179 Wevnt    0.0   20  CAS-client
> > > > 0a010052 179 Wevnt    0.0   23  CAS-client
> > > > 0a010051 180 Wmutex   0.0   19  CAS-event
> > > >
> > > > As you can see, no thread is using more then one quarter of its
> > > > allocated stack space.
> > > >
> > > > The current stack allocations are:
> > > >    epicsThreadStackSmall:  stackSize =  8000
> > > >    epicsThreadStackMedium: stackSize = 12000
> > > >    epicsThreadStackBig:   stackSize = 16000
> > > >
> > > > Perhaps these could be reduced by 30 to 50 percent???
> > > >
> > > >
> > > > Each client results in the allocation of a 'Big' stack for the CAS-
> > > > client thread and a 'Medium' stack for the CAS-event thread.
> > > >
> > > > --
> > > > Eric Norum <norume@aps.anl.gov>
> > > > Advanced Photon Source
> > > > Argonne National Laboratory
> > > > (630) 252-4793
> > --Eric Norum <norume@aps.anl.gov>
> > Advanced Photon Source
> > Argonne National Laboratory
> > (630) 252-4793
--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793