Date: Wed, 30 Oct 2002 15:29:24 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Doug Rabson <dfr@nlsystems.com>, Peter Wemm <peter@wemm.org>, Nate Lawson <nate@root.org>, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <3DC06B54.A67E555B@mindspring.com> References: <20021030214158.CB6EA2A88D@canning.wemm.org> <20021030221417.J22480-100000@herring.nlsystems.com> <20021030230723.GE42580@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (Oct 30), Doug Rabson said: > > On Wed, 30 Oct 2002, Peter Wemm wrote: > > > We've been over this before. To make this work right, we need to > > > make /bin and /sbin dynamically linked. NetBSD's /rescue/* > > > approach would solve the "oops!" and other foot shooting problems. > > > > Yes please. Our root filesystem space requirements are too high, > > IMHO. > > Note that dynamically-linked executables take significantly longer to > exec than statically-linked ones. Running the following simple script > with getfacl and grep linked dynamically runs a little over twice as > slow as with them both static: I can't tell if the time difference is coming from where you say it's coming from, or if it's coming from somewhere else. If it's coming from where I think it's coming from, the answer is very easy: in the original ELF specification, the program offset in the UVM was very large, to permit "enough room" for the kernel to pre-mmap both the ld.so and the libc.so into the address space of each program before it started, making the decision after it faulted in the first page. This was the intentional design of the ELF initial offset being so large. Basically, this means that the template process that's used to start new processes following an exec can have a preinitialized shared address space for these areas, which will save the overhead that's probably contributing most to the problem. In other words, this is an exec/crt0 problem, not a static vs. dynamic problem. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC06B54.A67E555B>