This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: memory saving scheme for stacks
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