Date: Tue, 3 Jun 2003 09:45:54 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root Message-ID: <Pine.NEB.3.96L.1030603093856.70933C-100000@fledge.watson.org> In-Reply-To: <16092.36129.388194.477452@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Jun 2003, Andrew Gallatin wrote: > > > Webservers and all other applications which run shell scripts exec a > > > shell to interpret that script. Regardless of how the parent is > > > linked, if the exec'ed shell is dynamically linked, there is an added > > > cost to exec'ing it. > > > > and these are usually perl, php, or compiled cgi programs, not /bin/sh. > > Ok, maybe a webserver is a bad example. But you must admit that /bin/sh > is commonly used outside the startup scripts. I think this is an area where an investment of time in prebinding may have a substantial payoff. Matt Dodd has been doing some experimentation on a number of different prebinding approaches, and has demonstrated pretty measurable performance improvements for common dynamically linked applications (of which we have a number that would really benefit from it). Presumably prebinding wouldn't 100% recover the cost of a switch to dynamic linking for a static binary, but it could well recover 90%. Hopefully Matt can post some of his initial experimentation results in the next few weeks as they become more mature. Unfortunately, the /bin/sh case really does appear to be the most pessimal case for even optimized dynamic linking: sh has a sufficiently short run time and small enough memory footprint that the reduced memory overhead of using shared memory for its libc access presumably doesn't outweight the startup costs. There are presumably environments where sh is invoked a lot -- perhaps in some CGI environments, during large builds, etc. I'd be very interested in seeing some performance results there. Unfortunately, our benchmarking capacity for things like this is a bit limited while the 5.x kernel still has lower I/O throughput due to fine-grained locking not hitting some of the storage subsystems. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030603093856.70933C-100000>