Re: [ECOS] memory saving scheme for stacks

[sandeep <sandeep at codito dot com>]

> 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.
Good, someone can continue from abstract end, and some on list can help the 
abstract thinker with the issues from the other (implementation) end.

U mean that not-executing threads' stacks will be adjacent to each other in some 
global pool.

? will this big pool be dynamically allocated? or pre-kept-aside

? what about the size of this big pool? wouldn't it be required to have it big 
enough to hold maximum saved stacks of all the non-executing threads? (since as 
of now i don't know if you have separate notions of SST and normal threads, see 
further for what i intend to ask by this). if that's the case then as much 
memory you have blocked as you would have by having N separate stacks (N = 
number of threads).

? i guess, this pre-kept-aside big pool will not be sufficient for cases where 
lots of threads may get created dynamically. you might not have any estimate of 
them beforehand - may be you once run under identical conditions to get some 
idea of it and use some margin.

? what i gather from your explanation, saved stacks will be looking like -
  ss1,ss2, ss3, ...,ssN

and the addresses of ss<i> is stored in corresponding thread structure (the 
length of this area could be either stored in first word of this area, or as a 
part of thread structure).

Now next time say, ss3 is loaded back. that will mean a hole in pool b/w ss2 and 
ss4. will this hole be used to store being-switched-out guy's stack? but it 
might not be sufficient size?

fragmentation will result in global pool that needs to be handled and needs 
additional compute/time resources.

? there is this issue of - do you check if enough space in pool to store the 
currently moved out guy's stack? say if not enough then what do you do? some 
sort memory compaction (this has further issues involved, if we go into this, 
then will blah blah on this).

btw, are you proposing to have two separate kind of threads - normal and SST ?
do you plan different treatments for them altogether from eCos? otherwise what 
will the use of two categories be, if SST is just like any normal thread apart 
from user writing the thread code in a way to decide where the thread could or 
couldn't be scheduled out.

and, SST will be making calls to rest of the eCos also, like normal threads. in 
that case notion of SST needs to be percolated throughout???

--
regards
sandeep
--------------------------------------------------------------------------
"Every morning, I get up and look through the 'Forbes' list of the
richest people in America.  If I'm not there, I go to work"
		-- Robert Orben
--------------------------------------------------------------------------


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