Subject: Re: RFC: migration to a fully dynamically linked system
To: Todd Vierling <email@example.com>
From: sudog <firstname.lastname@example.org>
Date: 12/21/2001 12:11:23
> : Besides, if static copies are noticeably faster, then why would I (as a
> : rhetorical virtual hoster of masses of websites, for example) want to
> : take a performance hit just to save a few megabytes of RAM?
> Depends on how you define "noticeably faster" here. If you have a lot of
> memory (which you imply here), the needed pages of libc.so and ld.so
> be in-core, so the only startup overhead is linking perhaps a dozen
> I'd be interested to see benchmarks on this....
Me too. I think "a few" might be a little misleading. In a simple hello
world dynamically linked app, the amount of function calling going on is
truly horrendous. Assuming nothing has changed since I wrote my dinky
"Adventures in Assembly" stories. gdb'ing through a dynamically linked
executable was extremely painful, as I mentioned there. Surely complexity
of that order is logically enough to impact performance in *some* way. :)
> The argument doesn't hold up well, given the fact that only /bin and
> are static. If you want "static binary speed increases", then you can
> simply rebuild the whole system yourself statically. You can do it with
> mk.conf switch: "MKPIC=no". 8-)
Mmm.. Magic recipes. Now *this* is the kind of stuff we should slap into
the FAQs and NetBSD howtos. Ah, there it is. mk.conf manpage. :)
> : And I can't count on my hands and feet the number of times that busy
> : (millions of hits/day) Linux systems under my care have died because
> : something went bad and puked all over either libc, or libc and the
> : linker, making the entire thing useless until someone arrived on-scene
> : with a boot-disk.
> And how is this situation different from something puking on NetBSD's
> /sbin/init binary...?
Not a clue. It's never happened on a NetBSD machine under my supervision.
Ever. Which is neat. Not that I haven't I've had some pretty nasty
problems--one fs problem where the filesystem got to a state that panic'd
the kernel when a certain file was accessed... something about a duplicate
node..? I wish I had recorded the failure a little more diligently...
> On a related note, if you're paranoid about trashed critical files, you
> should have a netbsd.INSTALL.gz located on at least one of your
> (hopefully all of them). That helps catastrophic recovery a lot -- take
> from experience.