Re: [ECOS] memory saving scheme for stacks

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

On Fri, 2004-07-23 at 13:50, sandeep wrote:
> > 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

allocated at startup time before SST threads are launched.

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

Yes.

> (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).

No.

The size of this buffer is the sum of the maximum stack usage outside
cyg_thread_ss_suspend/resume(), which it should be possible to determine
with great confidence.

The shared global stack amongst SST threads would have to be the size of
the maximum stack usage of SST threads.

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

Certainly.

> btw, are you proposing to have two separate kind of threads - normal and SST ?

Yes.

> do you plan different treatments for them altogether from eCos?

No.

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

As far as I can see, only SST threads needs to be aware of SST threads.
SST threads can make calls to eCos in the same fashion as normal
threads.

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