From owner-freebsd-arch Fri Nov 10 5:40:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (mobile.wemm.org [202.12.86.17]) by hub.freebsd.org (Postfix) with ESMTP id E815937B479; Fri, 10 Nov 2000 05:40:25 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eAADeEW34342; Fri, 10 Nov 2000 21:40:15 +0800 (WST) (envelope-from peter@netplex.com.au) Message-Id: <200011101340.eAADeEW34342@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matt Dillon Cc: Mike Smith , Alfred Perlstein , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011092322.eA9NMHN12920@earth.backplane.com> Date: Fri, 10 Nov 2000 21:40:14 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > :Um. And root on a BSD box is equally screwed when there's no memory left > :to map in the text segment of 'ps' which just happens to contain another > :copy of libc. > : > :The difference being that if libc is shared, it's already mapped in for > :the hundreds of other programs using it, so you're *better* off, not > :worse. > > This is not exactly true. The difference between the static binary and > shared binary is that *ALL* the text pages in the static binary are > clean. A shared binary dirties many, many more pages to generate the > library relocations - as much as 60K for a simple program that links > into libc. Text in a shared binary (and library) is clean too. All references go via the PLT and GOT.. and *they* are what get relocated and backed by swap. The more relocations, the larger this will be. > So in a low memory situation the static binary will win, because clean > pages use the already-existing binary file image as backing store and > do not have to go to swap. They can simply be discarded. *A* static binary, yes. If you are only using the one binary for all processes. I doubt many real-world out-of-memory situations are all due to a a single static vs. dynamic 'ps' binary shared 300+ times.... More likely it'd be a runaway httpd or something, which are almost always shared anyway. Trying to run a static ps is going to need ~330K of ram. Trying to run a dyanmic ps is going to need ~25K of ram for the text+data and ~60K or so for the PLT/GOT glue, plus it will hook onto the already-present libc.so pages for text and COW any libc.so data pages... Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message