[EMAIL PROTECTED] wrote: > > > Would it be usefull to create a kernel flag to mark all process stack > > memory with |MAP_NORESERVE|, e.g. don't allocate swap memory for stacks > > ? The idea is to reduce the swap requirements for platforms like settop > > boxes etc. with limited or no swap space by exploiting the detail that > > almost all applications reserve memory for large stacks (8MB default) > > but only use a tiny fraction (most shells and shell applications rarely > > use more than 64k). > > When you say, "limited or no swap space," what are you really talking > about here? Solaris can use both memory and disk as reserved memory > swap. Check out anon_resvmem() in the kernel. It can take pages from > either a swap device or memory.
I was thinking about the traditional Unix view of a "swap slice", e.g. a settop-box may only have flash memory and no swap disk/slice etc. > If you have a fininite amount of resource, using MAP_NORESERVE means > that your failure mode for overuse will be non-deterministic. I.e. > you'll get a SIGBUS or SIGSEGV when you try to write to the stack and a > page cannot be allocated. ... my point is that if the machine only has 128MB and no swap (disk) is available (e.g. LiveDVD) then every single wasted memory page is one too much. AFAIK (looking at pmap output of a few processes of a B48/SPARC machine) many processes never use all the stack they reserve by default. Even if one process uses it's stack more extensively the others won't do that, leaving lots of memory pages reserved but unused. Some (very wrong and raw) calculations: Imagine a system has 50 processes where each process has a 8MB stack: 50*8MB=400MB If each process only uses 1MB of it's 8MB reserved stack memory you "waste" ~~350MB (in theory) One option would be to reduce the default stack size - but that causes trouble for applications which have been optimized to use more stack (which adds some nasty error/failure cases anyway) - therefore it may (IMO) be better to keep the current stack size at it's current value and change the way how the stack memory is reserved (since the average stack usage of all processes is _far_ below the maximum stack size). > I'm in favor of the more deterministic method > of having the failure occur at allocation time because we're out of > memory. (It's easier to debug too) Right... but in the case of a LiveDVD (which is mainly used for demostration) it (AFAIK) matters more that it _runs_ on small machines - the correctness is AFAIK secondary in this case (e.g. the "correct" approach for a permanent installation would be the creation of a swap slice and turn the proposed flag "off"). Note: I am not proposing to turn such a flag "on" by default but I think it may be valueable for cases like the BeleniX LiveDVD... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
