[ECOS] memory saving scheme for stacks

Øyvind Harboe oyvind.harboe@zylin.com
Fri Jul 23 11:23:00 GMT 2004


On Fri, 2004-07-23 at 12:19, sandeep wrote:
> Please see my comments inline. Correct me, if I am straying in understanding 
> what you are proposing.
> 
> > In my system I have a number of threads that typically do a bit of
> > processing and then long periods of sleep.
> > 
> > Since only one thread can run at any one time, there is lots of 
> > unused stack memory at any moment in time. This can be as much as 20% of
> > the overall memory in the system. Ignore SMP systems here.
> > 
> > A scheme to reclaim this memory comes to mind:
> > 
> > - When a thread is created, it is marked as being special:
> > "stacksaving-thread". SST for short.
> > - Only one SST thread runs at any one time.
> > - All SST share the same stack memory location.
> > - When SST thread is switched out, the portion of the stack that is in
> > use is saved off to a different memory location.
> where will be this memory location? Since this memory location has to be 
> separate for each thread, and you stack could be maximum configured size at 

It does not have to be seperate for each thread.

> times during switching, you need to make sure enough size is reserved at your 
> save location.

The area where the stack-in-use is saved off would have to be a shared
global memory area where the used stack is stored back-to-back. 
I believe that it is relatively straightforward matter to implement such
a storage facility, thus I haven't clouded my first explanation with
implementation issues. 

> > - When a SST thread is switched in, the portion of the stack that is in
> > use is restored from the saved off location.
> > - The threads in my system typically have 200-1000 bytes of stack in use
> > at any one time => memory copy shouldn't bring the system to its knees.
> In situations where you have many thread switchings, you would want to have 
> context switching as fast as possible. Context-switch time is moreorless 
> constant, above scheme will make it variable b/w a minimum and maximum 
> (depending upon the maximum configured) stack size, can vary from configuration 
> to configuration.

Obviously there is a CPU/memory tradeoff here. Each application will
have to figure out which threads should be SST and which should be
normal threads.

If you have the ram, then obviously SST threads make no sense.


-- 
Øyvind Harboe
http://www.zylin.com



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list