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


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


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