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 = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute or [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
