HEADS UP: new NSS

Dan Nelson dnelson at allantgroup.com
Thu Apr 17 20:21:50 PDT 2003


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
-------------- next part --------------
0x8048000 0x804d000 5 0 0xc5be5850 r-x 1 0 0x0 COW NC vnode
0x804d000 0x804e000 1 0 0xc5c70e40 rw- 2 0 0x2180 NCOW NNC default
0x804e000 0x8066000 24 0 0xc5c70e40 rwx 2 0 0x2180 NCOW NNC default
0x2804d000 0x28063000 20 0 0xc3b535f0 r-x 157 73 0x4 COW NC vnode
0x28063000 0x28064000 1 0 0xc64ce130 rw- 1 0 0x2180 COW NNC vnode
0x28064000 0x28066000 2 0 0xc5b035f0 rw- 2 0 0x2180 NCOW NNC default
0x28066000 0x2806e000 6 0 0xc5b035f0 rwx 2 0 0x2180 NCOW NNC default
0x2806e000 0x28086000 13 0 0xc3b9de40 r-x 54 36 0x4 COW NC vnode
0x28086000 0x28087000 1 0 0xc62bf098 r-x 1 0 0x2180 COW NNC vnode
0x28087000 0x2808c000 5 0 0xc54562f8 rwx 1 0 0x2180 COW NNC vnode
0x2808c000 0x280c2000 51 0 0xc3de8688 r-x 25 16 0x4 COW NC vnode
0x280c2000 0x280c3000 1 0 0xc6ad1130 r-x 1 0 0x2180 COW NNC vnode
0x280c3000 0x280cc000 9 0 0xc6c3fd10 rwx 1 0 0x2180 COW NNC vnode
0x280cc000 0x2818a000 131 0 0xc5e05688 r-x 1 0 0x2180 COW NNC vnode
0x2818a000 0x2818b000 1 0 0xc6d56390 r-x 1 0 0x2180 COW NNC vnode
0x2818b000 0x28190000 5 0 0xc5bc1558 rwx 1 0 0x2180 COW NNC vnode
0x28190000 0x281a3000 13 0 0xc4f6aed8 rwx 1 0 0x2180 NCOW NNC default
0xbfbe0000 0xbfc00000 4 0 0xc5b14260 rwx 1 0 0x2180 NCOW NNC default

$ ldd dyn
dyn:
        libm.so.2 => /usr/lib/libm.so.2 (0x2806e000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x2808c000)
        libc.so.5 => /usr/lib/libc.so.5 (0x280cc000)
-------------- next part --------------
0x8048000 0x80c4000 124 138 0xc5df32f8 r-x 2 1 0x0 COW NC vnode
0x80c4000 0x80c5000 1 0 0xc4caa688 rw- 1 0 0x2180 COW NNC vnode
0x80c5000 0x80d5000 10 0 0xc4f3b688 rw- 2 0 0x2180 NCOW NNC default
0x80d5000 0x80ed000 24 0 0xc4f3b688 rwx 2 0 0x2180 NCOW NNC default
0x280c4000 0x280c5000 1 0 0xc3e7d098 rwx 1 0 0x2180 NCOW NNC default
0xbfbe0000 0xbfc00000 4 0 0xc64c9ed8 rwx 1 0 0x2180 NCOW NNC default


More information about the freebsd-current mailing list