ten thousand small processes

[Terry Lambert]

"D. J. Bernstein" wrote:
> Chuck Swiger writes:
> > Remember that VMM hardware requires page-alignment
> 
> When I ask why the stack and data aren't put on the same page, and you
> say ``They aren't on the same page,'' you aren't answering the question.
> (As for adding an x bit to data: This obviously won't break anything.)

I don't know if you just ignored my posting where I answered this,
but I will answer it yet again: to prevent data from being made
executable.  The stack, at present, *must* be executable, since
it must support the signal trampoline code, which is code that
executes on the stack.


> Here's an alternative layout that doesn't move the text. Subtract the
> data+bss (or at least data) amount from the stack starting position, and
> put the data+bss (or data; but not the heap, obviously) into that space.
> This saves 78 megabytes of memory in the situation I'm talking about.

The stack and data cannot share the same page, while leaving the
stack executable and the data not.  I am also not sure how it is
we are supposed to judge the maximum stack size at compile/link
time.


> > Mach uses copy-on-write
> 
> I'm not talking about copy-on-write. I'm not talking about shared pages.
> I'm talking about RAM being frittered away for memory-management tables
> that, in this situation, could trivially be compressed by two orders of
> magnitude. This is not rocket science.

I don't believe this is explicitly possible, due to architectural
constraints.  You either get ~1,810 processes less than you want,
because you use a GDT entry per process, or you don't get write
fault notification for the purposes of implementing COW for the
page tables.

-- Terry