From owner-freebsd-hackers Tue Feb 27 12:23:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4F73A37B71B for ; Tue, 27 Feb 2001 12:23:43 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14Xqdm-00045h-00; Tue, 27 Feb 2001 20:22:34 +0000 Date: Tue, 27 Feb 2001 20:22:34 +0000 From: Tony Finch To: Lyndon Nerenberg Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Re: Setting memory allocators for library functions. Message-ID: <20010227202234.K609@hand.dotat.at> References: <20010227013743.H609@hand.dotat.at> <200102271936.f1RJaFq98998@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102271936.f1RJaFq98998@orthanc.ab.ca> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lyndon Nerenberg wrote: > >If the information in the data segment is going to be updated then >you have to have writable backing store. If, however, that data >is never going to be changed, it should be declared in the program >as read-only data. The kernel VM system should not be working around >applications that don't declare their data arena correctly. In most cases it is impossible to declare the data read-only because it originally had to be read-write and you can't change its attributes later. This is always the case for malloc(). Many applications do a load of initialization that requires read-write memory then never write to that memory again; when they fork the OS still has to account for that memory twice even if it is going to be immediately discarded by an exec(). An even more exaggerated example is Apache which forks a load of times then hangs around for ages. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at MALIN: NORTHEAST 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 IN SOUTHEAST AT FIRST, DECREASING 5. SNOW SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message