Re: HEADS UP: new NSS

In the last episode (Apr 17), Robert Watson said:
> On Thu, 17 Apr 2003, Dan Nelson wrote:
> > > If switching to a fully dynamically linked system is desired
> > > before 6.0 then it needs to happen before 5.2.  I'm not opposed
> > > to this.
> > 
> > I'm more worried about the performance hit than foot-shooting (schg
> > is protection enough I think, and I like beagles).
> > 
> > I believe dynamically-linked programs still are ~20% slower than
> > static ones, and for small programs like sed, awk, expr, sh,
> > basename, tr, and the like, the larger (constant) startup time
> > becomes significant also.
> > 
> > Anyone want to benchmark a medium-sized portbuild with static vs
> > /dynamic bin and /sbin?
> 
> Well, I think that the measurements should be done, but it's worth
> noting that several of the programs you quote above have been
> dynamically linked for years:
> 
> sed		dynamic
> awk		dynamic
> expr		static
> sh		static
> basename	dynamic
> tr		dynamic

Oops.  I forgot I statically link quite a lot of /usr/bin on my system.
 
> Some might argue that even to support NSS, expr wouldn't need to
> become dynamic.

Right; very few programs actually would need to be converted to
dynamic.  But John brought up a totally dynamic system, which I think
would be a bad idea, performance-wise.

> One of the noted benefits of running with a dynamic system is that
> you can actually save a fair amount of memory by not requiring
> separate physical memory storage for each instance of libc.  There
> are a number of trade-offs, and we're certainly not the first to
> approach this decision :-).  I'd be very interested in seeing some
> micro-benchmark and macro-benchmark performance results, however.

Yeah, but that's what, maybe 500k per executable (not per-process,
since those pages will get shared)?  Contrast that with all the pages
(per-process) in the shared library that have offsets to get fixed up
that can't be shared.  I ran a quick test by building dynamic and
static copies of ls, running ls -R /usr/ports, then pausing both with
^Z.

(root_at_dan.3) /tmp># ps axl | grep ls\.
  UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT  TT       TIME COMMAND
    0 90081 83712   0  96  0   792  680 -      T     p4    0:00.02 ./ls.stat -l -R /usr/ports
    0 90132 83712   0  96  0  1616 1196 -      T     p4    0:00.03 ./ls.dyn -l -R /usr/ports

It /looks/ like the dynamic version uses more memory, although that may
just be because it ends up mmapping the whole of libc, libm, and
ncurses instead of just the required bits.  So a lot of those pages
probably end up shared.

I've also attached /proc/pid/map files for both processes for anyone
that can decode them and figure out exactly how many unshareable pages
the dynamic version has.

-- 
	Dan Nelson
	dnelson_at_allantgroup.com