From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 21:30:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 592D916A4CE; Tue, 18 Nov 2003 21:30:25 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21FBF43FCB; Tue, 18 Nov 2003 21:30:24 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAJ5UNXF028093; Wed, 19 Nov 2003 00:30:23 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 19 Nov 2003 00:30:21 -0500 To: Robert Watson , David Schultz From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: dyson@iquest.net cc: current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 05:30:25 -0000 At 11:45 PM -0500 11/18/03, Robert Watson wrote: > >My feeling is we should all go away for a day or two, and run >our favorite macro-benchmark on our favorite sensitive dynamic >linking-sensitive application. I wish I had the time and background to implement one solution that I'd like to benchmark. have a: chflags ldcache /bin/sh When the loader goes to execute some binary, it checks for this ldcache flag. If set, it checks to see if it already has a cached copy of this program (probably checking based on a key of inode+lastchg for a match). If not, it links and loads the file into memory. It saves away a read-only copy of the result of that load. Then it does the appropriate magic to create a copy-on-write image of the loaded file, and executes that. If it already has a cached copy of that file, well, it just makes another copy-on-write image of the loaded file, and executes that. No I/O, no loading, no linking. Just RAM. Yes, disks have been getting bigger, but so has available memory. I think we would see a MUCH bigger win by taking advantage of that memory, than we will ever see by statically-linking system binaries. On the other hand, I have no idea if the above idea would be easy to implement in FreeBSD. It also needs to be a bit smarter than what I described, to cover the dynamic-library case (eg: the very PAM/NSS issue that we're interested in). If that isn't workable, I'm sure there are other strategies which could be imagined. Strategies which will give us more of a performance boost than static-linking these few programs will give us. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu