> 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
_______________________________________________
appliances-discuss mailing list
appliances-discuss opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss
|
