From owner-freebsd-performance@FreeBSD.ORG Sun Jun 22 00:50:35 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 90B8437B401 for ; Sun, 22 Jun 2003 00:50:35 -0700 (PDT) Received: from svaha.com (svaha.com [64.46.156.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8817943FA3 for ; Sun, 22 Jun 2003 00:50:34 -0700 (PDT) (envelope-from meconlen@obfuscated.net) Received: from presa (24161248hfc18.tampabay.rr.com [24.161.248.18]) (AUTH: LOGIN meconlen) by svaha.com with esmtp; Sun, 22 Jun 2003 03:50:31 -0400 From: "Michael E. Conlen" To: "D. J. Bernstein" , freebsd-performance@freebsd.org Date: Sun, 22 Jun 2003 03:50:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030621185821.30070.qmail@cr.yp.to> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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: Sun, 22 Jun 2003 07:50:35 -0000 If your going to get this serious about your memory management, couldn't you just brk yourself and manage it your self? You seem to know exactly what your looking for and expect a specific result. I wouldn't recommend it to most, but you seem to know what your doing. -- Michael Conlen -----Original Message----- From: owner-freebsd-performance@freebsd.org [mailto:owner-freebsd-performance@freebsd.org]On Behalf Of D. J. Bernstein Sent: Saturday, June 21, 2003 2:58 PM To: freebsd-performance@freebsd.org Subject: ten thousand small processes FreeBSD 4.8. Test program: malloc(360); malloc(80); malloc(180); malloc(16); malloc(440); sleep(10); _exit(0). Compile statically. The program ends up with 44KB RSS. Where is all that DRAM going? The program also ends up with 168KB VSZ. Where is all that VM going? I don't care much about the 3-page text segment. But I do care about the 39 extra pages of VM, and the 8 extra pages of DRAM. There's no obstacle to having a small program fit into _one_ page per process; two or three can be excused, but 39 is absurd. (Yes, I know that Solaris is worse.) At least 2 pages appear to be wasted by exit(), because it brings in a chunk of stdio, which uses 84 bytes of data and 316 bytes of bss. The libc implementors clearly don't care about 316 bytes of memory, so why don't they make those 316 bytes static? Why doesn't the compiler automatically merge some bss into data when that saves a page? Why can't I omit exit(), manually or automatically, when it's unreachable? Furthermore, malloc() appears to chew up a whole new page of DRAM for each allocation, plus another page---is this counted in VSZ?---for an anonymous mmap. Would it really be that difficult to fit 1076 bytes of requested memory into the 3000-odd bytes available at the end of bss? I sure hope that there's some better explanation for the remaining 32 pages than ``Well, we decided to allocate 131072 bytes of memory for the stack,'' especially when I'm hard-limiting the stack to 4K before exec. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"