> 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.
I think that in this case, as long as you don't configure the flash disk to be part of a swap partition, the kernel will reserve physical memory as swap instead. > > 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. I don't understand this reasoning. I agree that we don't want to waste memory in this situation. However, in the case of 128MB mem and no swap device, a call to anon_resvmem() will simply deduct the amount of memory that is available to the system by the size of the requested reservation. This is necessary because we've taken a pagefault in the stack at this address and need pages to back the VA we've allocated. As far as I understand it, these pages aren't being wasted because we're _using_ them as part of the stack. > 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. I disagree with this statement. The anon reservation is made at the time the stack pages are allocated. This happens when we get a pagefault in the process' stack. The memory will only be reserved if it is going to be used by the process. This is because the pagefault occurs when the unmapped area of the stack is accessed. > 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) I'm not sure I understand where you're getting 8MB as a size for a stack? A random sample of processes that I pmap'd had a 16k-24k stack. > 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 The stack size is grown as needed. The memory isn't reserved until we grow the stack. > (since the average stack usage of all processes is _far_ below the > maximum stack size). Yes, and therefore the amount of anonymous memory reserved is, on average, much smaller than the maximum stack size. > 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"). I think it needs to do both: run and be correct. Is there an actual problem you're seeing with a LiveDVD? -j _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
