Date: Fri, 10 Nov 2000 21:18:48 +0800 From: Peter Wemm <peter@netplex.com.au> To: Alfred Perlstein <bright@wintelcom.net> Cc: Mike Smith <msmith@FreeBSD.ORG>, Matt Dillon <dillon@earth.backplane.com>, Warner Losh <imp@village.org>, arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <200011101318.eAADImW34016@mobile.wemm.org> In-Reply-To: <20001109144747.E5112@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
> * Mike Smith <msmith@FreeBSD.ORG> [001109 14:35] wrote:
> > > * Matt Dillon <dillon@earth.backplane.com> [001109 11:11] wrote:
> > > >
> > > > I'd recommend against the linux /lib + /usr/lib model, it's a big
> > > > mess. I don't see much of a point in cutting the size of /bin and
> > > > /sbin down, they are already fairly small (3.8M and 10M) and it
> > > > isn't as though we need the disk space! The static nature of
> > > > /bin and /sbin have saved me more times then I can remember. I als
o
> > > > have unfond memories of blowing /lib up under linux and not being
> > > > able to do anything.
> > >
> > > root on a Linux box is unable to do squat when the machine is almost
> > > out of memory because he can't map in /lib/libc.so to run 'ps' or
> > > even another copy of bash.
> >
> > Um. And root on a BSD box is equally screwed when there's no memory left
> > to map in the text segment of 'ps' which just happens to contain another
> > copy of libc.
> >
> > The difference being that if libc is shared, it's already mapped in for
> > the hundreds of other programs using it, so you're *better* off, not
> > worse.
>
> The real difference here is that I've seen several instances of a
> Linux box unable to cope with this situation and a FreeBSD box
> cope. Linux locked up and FreeBSD 'gracefully' shot a process dead
> and free'd up some memory.
>
> What "should" happen versus what _did_ happen doesn't make what
> did happen untrue.
Just because Linux is braindead in this regard, doesn't mean we have
to be too.
BTW: kill is a shell builtin command. The real memory requirement is from
forking. If linux chooses to get silly about denying mmap() but still allowing
fork and copy-on-write, then that is their problem.
Besides, having a shared libc is a win for memory because you get the same
physical pages mapped in over and over again, rather than having many many
seperate copies of libc mapped into different processes with no sharing.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011101318.eAADImW34016>