Unfortunate dynamic linking for everything
Garance A Drosihn
drosih at rpi.edu
Tue Nov 18 21:30:25 PST 2003
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
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 at gilead.netel.rpi.edu
Senior Systems Programmer or gad at freebsd.org
Rensselaer Polytechnic Institute or drosih at rpi.edu
More information about the freebsd-current