This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: memory saving scheme for stacks


On Fri, 2004-07-23 at 12:03, Nick Garnett wrote:
> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
> 
> > 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.
> > - 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.
> > 
> > I'm sure this has been done before as I can't see anything that
> > indicates that this is impossible.
> 
> Wouldn't the save areas have to be as large as the stacks?

A large amount of the unused stack is allocated because there is no good
way of knowing how much stack is enough. With SST you allocate as much
stack as you think you need + 1*safety margin instead of n*safety
margin.

> Given that the threads could be interrupted and preempted at any point and any
> stack depth.

Fleshing out the idea a bit more:

Add a new kernel API where SST threads can indicate when they are
preemptable by other SST threads, i.e. when the thread usage is at its
lowest.

for (;;)
{
	// sleep here...

	cyg_thread_ss_suspend(); // do not let other SST threads run
	// do processing where stack usage is at its highest
	cyg_thread_ss_resume(); // let other SST threads run
}

> A better approach, would be to combine all these mostly idle threads
> into one service thread that simply waits for one of several events
> and services then as they arrive. But that does depend on the
> structure of your threads.

This is especially hard when the two threads cross modules, such as a
telnet + tftp thread.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]