Re: Unfortunate dynamic linking for everything

On Tue, 18 Nov 2003 dyson_at_iquest.net wrote:
> M. Warner Losh said:
> > In message: <200311181307.hAID7uHa032514_at_dyson.jdyson.com>
> >             dyson_at_iquest.net writes:
> > : 	It really doesn't make sense to arbitrarily cut-off a
> > : 	discussion especially when a decision might be incorrect.
> >
> > I'd say that good technical discussion about why this is wrong would
> > be good.  However, emotional ones should be left behind.  Except for
> > John's message, most of the earlier messages have been more emotional
> > than technical.
> >
> > John, do you have any good set of benchmarks that people can run to
> > illustrate your point?
> >
> I'll see if I can find some of my old benchmarks (from memory,
> not disk -- lots of stuff has rotted away.).  I had hoped
> to avoid doing much in the way of proof.  Pointing to the
> much more complex process map along with the implication
> for significantly higher overhead :-).  (The VM code generally
> gets slower with more complex process maps and more memory used.
> For smallish programs -- including those with a few shared libs,
> changing the VM code won't help much, because the cost is built
> in to the complexity of the process image.)

I'm glad that real arguments are finally starting to surface =-)

Our rationale for encouraging Gordon is as follows:

1.  4.x upgrade path:  As we approach 5-STABLE, a lot of users might want
    to upgrade from 4-STABLE.  Historically in 4.x, the / partition has
    been very modest in size.  One just simply cannot cram the bloat that
    has grown in 5.x into a 4.x partition scheme.  Of course there is the
    venerable 'dump - clean install - restore' scheme, but we were looking
    for something a little more user-friendly.

2.  NSS support out-of-the-box:  Again, this is a user-experience issue
    in that forcing NSS users to recompile world was seen as a potential
    roadblock to them.

3.  Binary security updates: there is a lot of interest in providing a
    binary update mechanism for doing security updates.  Having a dynamic
    root means that vulnerable libraries can be updated without having to
    update all of the static binaries that might use them.

4.  I've probably forgotten the other factors...

As for performance, we felt that the typical use of FreeBSD did not fall
into the category of doing forkbomb performance tests.  While there might
certainly be users that do continuously create lots of short-lived
processes, we felt that the above benefits outweighed this, but left the
door open for tailoring to this need (recompiling world with
NO_DYNAMICROOT).

If people really are concerned with the VM microbenchmarks associated with
complex process maps, then hopefully this is a challenge to look for
optimizations there.

Scott