40% slowdown with dynamic /bin/sh

[Dan Nelson]

In the last episode (Dec 02), Tim Kientzle said:
> Does that rule out NIS with a static root?
> 
> Yes, with the current NSS/PAM implementation, although a variety of
> suggestions have been floated around that would make NSS/PAM
> compatible with static binaries.  My personal favorite is to
> implement NSS/PAM daemons to satisfy such requests.  Such daemons are
> surprisingly simple to implement, in my experience.  I'm skeptical of
> efforts to use dlopen() with static binaries; static binaries don't
> have symbol tables, so there's no way to resolve references from the
> dlopen()-ed library back into the executable.
> 
> I'm curious, though.  The single most convincing argument so far in
> favor of a static root has been performance.  Doesn't the NIS network
> overhead swamp any performance gains from static linking?  I suspect
> you have other reasons for wanting a static root.  (Or do you only
> require certain executables to be static, such as /bin/sh?)

The programs in /bin or /sbin that link the NIS stuff in don't use it
all that often (rm, for example, will only do a user_from_uid call in
the -i case for a file not owned by the deleter), and unaccessed pages
in a static executable cause no performance hit.  I'm not sure that any
program in /bin or /sbin really does enough lookups for it to be a
speed factor.  Quite a few of the ones that pull in the NIS code really
do it for resolving hostnames.  /bin/sh is the best argument for an
external NSS lookup agent, since it should be fast but occasionally may
want to do NSS calls.

To list programs that pull in NIS:

ident /bin/* /sbin/* | awk '/^[^ ]/ { cmd=$1 } /nsdispatch/ { print cmd }' 

-- 
	Dan Nelson
	dnelson at allantgroup.com