This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: memory saving scheme for stacks
- From: sandeep <sandeep at codito dot com>
- To: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Fri, 23 Jul 2004 15:49:14 +0530
- Subject: Re: [ECOS] memory saving scheme for stacks
- References: <1090575003.17601.53.camel@famine>
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
times during switching, you need to make sure enough size is reserved at your
save location.
so where is your saving? the same amount of memory that you would have had as a
stack, now you are going to have as savelocation. And w/o gaining what you
intend to save, increasing the work at switching time.
- 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.
I'm sure this has been done before as I can't see anything that
indicates that this is impossible.
If whatever I mentioned above, holds out reasonable, then that explains why it
might not have been done before, though not impossible.
--
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