Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jun 2003 23:23:03 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "D. J. Bernstein" <djb@cr.yp.to>
Cc:        freebsd-performance@freebsd.org
Subject:   Re: ten thousand small processes
Message-ID:  <3EFA9147.6435E822@mindspring.com>
References:  <20030623030004.40078.qmail@cr.yp.to> <20030624203536.D17881-100000@mail.chesapeake.net> <20030626020455.51862.qmail@cr.yp.to>

next in thread | previous in thread | raw e-mail | index | archive | help
"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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EFA9147.6435E822>