Date: 26 Jun 2003 02:04:55 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> To: freebsd-performance@freebsd.org Subject: Re: ten thousand small processes Message-ID: <20030626020455.51862.qmail@cr.yp.to> References: <20030623030004.40078.qmail@cr.yp.to> <20030624203536.D17881-100000@mail.chesapeake.net> <20030625060629.51087.qmail@cr.yp.to> <3EFA28EF.9050400@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) 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. > 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. Jon's ``dynamic page-table creation'' terminology is pretty good. Of course, for processes with many pages of process-specific memory, the page table should be cached rather than being shared among processes; I'm not suggesting any change in how browser memory is handled. > It's easy to write a memory allocator that performs a specific case well; > writing a general purpose malloc is significantly more complicated, I'm not talking about replacing malloc() with a special-purpose allocator. I'm talking about adding a tiny bit of code to malloc() to magically take advantage of space that is being ignored right now. The savings in this situation go beyond those dozens of megabytes of magically reacquired RAM. There's a nasty spike in memory usage as soon as malloc() starts extending the heap; when a program's allocations fit into the magically reacquired RAM, the program also avoids the spike. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030626020455.51862.qmail>