From owner-freebsd-performance@FreeBSD.ORG Wed Jun 25 23:24:14 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD0A837B401 for ; Wed, 25 Jun 2003 23:24:14 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27F2543FFD for ; Wed, 25 Jun 2003 23:24:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfirs.dialup.mindspring.com ([165.247.203.124] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19VQB2-0001Aq-00; Wed, 25 Jun 2003 23:24:12 -0700 Message-ID: <3EFA9147.6435E822@mindspring.com> Date: Wed, 25 Jun 2003 23:23:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "D. J. Bernstein" References: <20030623030004.40078.qmail@cr.yp.to> <20030624203536.D17881-100000@mail.chesapeake.net> <20030626020455.51862.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a415d3f081818e80c68e04e070ffe91d00350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-performance@freebsd.org Subject: Re: ten thousand small processes X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 06:24:15 -0000 "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