From owner-freebsd-arch Sun Nov 5 13:15:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (unknown [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 1E82937B4C5; Sun, 5 Nov 2000 13:15:34 -0800 (PST) Received: by border.alcanet.com.au id <115209>; Mon, 6 Nov 2000 09:14:47 +1100 Content-return: prohibited Date: Mon, 06 Nov 2000 08:15:16 +1100 From: Peter Jeremy Subject: Re: cvs commit: src/etc rc To: Warner Losh Cc: "John W. De Boskey" , arch@FreeBSD.ORG Mail-followup-to: Warner Losh , "John W. De Boskey" , arch@FreeBSD.ORG Message-Id: <00Nov6.091447est.115209@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Oct 23, 2000 at 08:09:43PM -0600, Warner Losh wrote: >In message <20001023204336.A46026@bsdwins.com> "John W. De Boskey" writes: >: If you want the entropy to be saved into swap, it seems >: like we should add this type of functionality to rndcontrol. >: >: rndcontrol -w /dev/da0s1b # write entropy to end of partition >: rndcontrol -r /dev/da0s1b # attempt to read entropy from partition > >The problem with having a program do it is that our shutdown >proceedures won't always run that program. Rather than "rndcontrol -w /dev/foo" in /etc/rc.shutdown, have "rndcontrol -r /dev/foo" read entropy from /dev/foo and flag that the kernel should dump entropy to /dev/foo during its shutdown. This is the way crashdumps work. As for using the same space for entropy and crashdumps - make sure that if a panic occurs, the entropy is written before the crashdump. If the partition is big enough, the crashdump won't overwrite the entropy. If not, you'll use the crashdump to seed yarrow next time. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 5 14: 7:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 714C237B4CF for ; Sun, 5 Nov 2000 14:07:40 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id F199FF20 for ; Sun, 5 Nov 2000 14:07:39 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA26056 for ; Sun, 5 Nov 2000 14:07:39 -0800 (PST) Message-ID: <3A05DA28.DE3EE486@cup.hp.com> Date: Sun, 05 Nov 2000 14:07:36 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: source upgrading: bootstrap library Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, When source upgrading, we seem to hit the problem of missing functions/syscalls more often. The problem in general is this: When we maintain our sources and/or update our contributed sources, we use functions that exist on the system at that moment. The mkstemps functions are a good example. When we try to build the sources on an older machine (when upgrading for example) those "new" functions may not be present. This breaks the build and the upgrade path which currently is broken in a number of cases. There are multiple ways to solve (avoid) this. One way is is handling each case seperately, as is currently done for gcc. We build a FreeBSD specific library for gcc that contains functions we need to be backward compatible (see /usr/src/gnu/usr.bin/cc/cc_fbsd). We have a similar problem with libiberty and just recently with perl. Another approach is to build a bootstrap library as part of the bootstrap phase and have it contain any and all functions or compatibility shims we need to be able to upgrade. All bootstrap, build and cross- tools are to be linked against this library (in such a way that existing functions are used). I tend to favor the latter and plan to implement it. Let me know if you have any objections, alternatives, additions or questions. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 5 23:50:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 4EFC837B479 for ; Sun, 5 Nov 2000 23:50:17 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id BE4193A for ; Sun, 5 Nov 2000 23:50:16 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id XAA04678 for ; Sun, 5 Nov 2000 23:50:16 -0800 (PST) Message-ID: <3A0662B7.9B1406A@cup.hp.com> Date: Sun, 05 Nov 2000 23:50:15 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Request for Review: ABI/arch dependent MINSIGSTKSZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, With the different ABIs and architectures and thus different signal frames or stack requirements, having a single MINSIGSTKSZ is not really sufficient. I've put a patch on: http://people.FreeBSD.org/~marcel/minsigstksz.diff to allow for a more flexible or variable MINSIGSTKSZ. In general this is what's changing: o Add a sv_minsigstksz field to struct sysentvec, o Have sigaltstack use this field to compare the supplied stack size with the minimum required. o Move MINSIGSTKSZ from to to better have it match the requirements of the different architectures. Especially the ia64 ports needs enough stack. o Define a MINSIGSTKSZ for each "emulator" to the value defined by the "emulated" OS for improved compatibility. A note about the values of MINSIGSTKSZ used in the patch: o alpha & ia64: sizeof(struct sigframe) is rounded to the nearest multiple of 1024. A multiplication of 4 allows for recursion/nesting and is somewhat arbitrary. o i386: sizeof(struct sigframe) is rounded to the nearest multiple of 512. A multiplication of 4 allows for recursion/nesting and is somewhat arbitrary. o iBCS2: No real value known. Use 8192 to maintain current behaviour. o OSF1 & SVR4: Wait for maintainers to report real values before committing. o Linux: Values are equal to those used in a Linux kernel. Credit: The idea of a variable MINSIGSTKSZ is bde's, not mine. Your comments please, -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 3:10:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id CD2EB37B4D7 for ; Mon, 6 Nov 2000 03:10:05 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id MAA84179; Mon, 6 Nov 2000 12:09:57 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id MAA36381; Mon, 6 Nov 2000 12:09:57 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 6 Nov 2000 12:09:56 +0100 (CET) From: Marius Bendiksen To: Dag-Erling Smorgrav Cc: Matt Dillon , Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One question that probably interests many of us is, can tuning those > numbers reduce fsck time? Is fsck time strictly proportional to disk > size, or does the number of inodes and/or cylinder groups affect it? Yes. It is proportional to the number of inodes (data to be processed), number of cylinder groups (number of zones to seek between) and the complexity of the namespace. With IFS, for example, the fsck time is far from the level it is in FFS. This is simplified, though, of course. Other things come into it as well. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 3:12:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 0F46F37B479 for ; Mon, 6 Nov 2000 03:12:16 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id MAA84609; Mon, 6 Nov 2000 12:12:14 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id MAA36395; Mon, 6 Nov 2000 12:12:14 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 6 Nov 2000 12:12:14 +0100 (CET) From: Marius Bendiksen To: Matt Dillon Cc: Alfred Perlstein , Randell Jesup , arch@freebsd.org Subject: Re: Like to commit my diskprep In-Reply-To: <200011030339.eA33d9D43976@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you have a machine with a gig of ram, losing 4MB is REALLY not a big > deal. Er. Allow me to point out that you need to allow the database software to wire that ram for it to even be of any value, because what I'm concerned with here is the latency. Bandwidth can always be increased; getting down the latency and the interruptions in continous (non-random) access is a concern of mine, and indirection does not help this. Besides, managing extants is actually easier, unless you want to use a B+-tree approach, like HPFS does. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 3:22: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 529BE37B479 for ; Mon, 6 Nov 2000 03:21:57 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id MAA86434; Mon, 6 Nov 2000 12:21:55 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id MAA36434; Mon, 6 Nov 2000 12:21:55 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 6 Nov 2000 12:21:55 +0100 (CET) From: Marius Bendiksen To: Randell Jesup Cc: Alfred Perlstein , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1 track? Not really. Modern drives have internal caches and > generally aggressively read-ahead. There was an interesting paper in Actually, it is of some relevance, to avoid having to wait for the head to reposition to the next track. Of course, the improvement isn't all that large. > SIGOS (I think) around a year ago about inode locality, forward placement, > and storing small files in the inode, and how all of this interacted > with modern drives. Also, what is a "track" on a modern drive? ;-) I was referring to a physical track. Which complicates the matter even further, as we have no idea how logical layout maps to physical layout. > >As a side note, I've thought about abusing the actual inodes themselves to > >hold single indirect blocks. Opinions, apart from the general evilness of > >abusing the structures in such a fashion? > That sounds good. I'll see if I can find the time to run some tests on this. My scratchbox is finally (after months of waiting) arriving now. > I'm willing to help on this, though my time may be limited. I have > _extensive_ FS experience from my Amiga days, and also was the primary > disk-driver person and SCSI expert, and also did "archive" filesystems for > Scala. I've never hacked the internals of ufs, however, but I do know the > issues. Then you should probably grope for a consensus on aims =) Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 3:32:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 527B837B4CF for ; Mon, 6 Nov 2000 03:32:39 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id MAA88483; Mon, 6 Nov 2000 12:32:36 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id MAA36473; Mon, 6 Nov 2000 12:32:36 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 6 Nov 2000 12:32:36 +0100 (CET) From: Marius Bendiksen To: Wes Peters Cc: Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-Reply-To: <3A037FA1.75B1C328@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > With a 'disk hog' partition editor, this is simple to do. As you add each I was requesting a noninteractive feature. =). And this was implemented by Randell (IIRHNC). Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 3:36:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 939A537B4C5 for ; Mon, 6 Nov 2000 03:36:41 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id MAA89337; Mon, 6 Nov 2000 12:36:39 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id MAA36505; Mon, 6 Nov 2000 12:36:39 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Mon, 6 Nov 2000 12:36:39 +0100 (CET) From: Marius Bendiksen To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-Reply-To: <200011040532.eA45WEo65619@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Would this become a new filesystem, e.g. extfs v.s. ext2fs -- ufs v.s. > ufs2? If not, would there be some kind of conversion procedure or The time might be right for a u2fs, but that was not what he suggested that he could spend time on. I am working on something in this area, but progress has slowed to a crawl due to lack of time and hardware for testing. This will hopefully be resolved now. > would existing filesystem have to be backed up, reinitialised and > restored? Or instead, would the filesystem convert to the new format > on the fly? Any decent future format would hopefully be able to handle on-the-fly conversions. I've got the stubs for a fat16->ffs converter here, it doesn't seem to be all that hard to do conversions. The problem lies with restartability. But if you design for this ahead, you have no problem. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 18:46:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id AC63637B4C5 for ; Mon, 6 Nov 2000 18:46:53 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA72kF271154; Mon, 6 Nov 2000 18:46:15 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Nov 2000 18:46:15 -0800 (PST) From: Matt Dillon Message-Id: <200011070246.eA72kF271154@earth.backplane.com> To: Kirk McKusick Cc: arch@FreeBSD.ORG Subject: softdep panic due to blocked malloc (with traceback) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This occured during low-memory deadlock testing: -Matt (pageout daemon) A blocked malloc in the pageout daemon with a softdep lock held: #2 0xc0238f93 in vm_wait () at ../../vm/vm_page.c:891 #3 0xc0232d58 in kmem_malloc (map=0xc02db6a0, size=16384, flags=0) at ../../vm/vm_kern.c:361 #4 0xc015bb47 in malloc (size=16384, type=0xc02c0c20, flags=0) at ../../kern/kern_malloc.c:188 #5 0xc0223321 in softdep_disk_io_initiation (bp=0xcf379220) at ../../ufs/ffs/ffs_softdep.c:2807 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here #6 0xc01964c3 in spec_strategy (ap=0xdca8fbdc) at ../../miscfs/specfs/spec_vnops.c:412 #7 0xc0195fe1 in spec_vnoperate (ap=0xdca8fbdc) at ../../miscfs/specfs/spec_vnops.c:117 #8 0xc022f31d in ufs_vnoperatespec (ap=0xdca8fbdc) at ../../ufs/ufs/ufs_vnops.c:2303 #9 0xc022ed55 in ufs_strategy (ap=0xdca8fc20) at vnode_if.h:923 #10 0xc022f2ed in ufs_vnoperate (ap=0xdca8fc20) at ../../ufs/ufs/ufs_vnops.c:2285 #11 0xc018369f in bwrite (bp=0xcf379220) at vnode_if.h:923 #12 0xc021f3e3 in ffs_balloc (ap=0xdca8fd40) at ../../ufs/ffs/ffs_balloc.c:316 #13 0xc0228119 in ffs_write (ap=0xdca8fd90) at vnode_if.h:1035 #14 0xc023d3fb in vnode_pager_generic_putpages (vp=0xe191fd80, m=0xdca8fea0, Caused a panic to occur here in the update daemon: #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c) at ../../ufs/ffs/ffs_softdep.c:262 #11 0xc02207a6 in softdep_process_worklist (matchmnt=0x0) at ../../ufs/ffs/ffs_softdep.c:546 #12 0xc018b26b in sched_sync () at ../../kern/vfs_subr.c:1034 #13 0xc02542a0 in fork_trampoline () cannot read proc at 0 (kgdb) frame 10 #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c) at ../../ufs/ffs/ffs_softdep.c:262 262 panic("softdep_lock: lock held by %d", lk->lkt_held); (kgdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 6 19: 0:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id D712037B4C5 for ; Mon, 6 Nov 2000 19:00:25 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA730PG71275; Mon, 6 Nov 2000 19:00:25 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Nov 2000 19:00:25 -0800 (PST) From: Matt Dillon Message-Id: <200011070300.eA730PG71275@earth.backplane.com> To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Whoops, never mind... I see the commit (was Re: softdep panic due to blocked malloc (with traceback)) References: <200011070246.eA72kF271154@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bleh. What I get for not updating my cvs tree for a few weeks :-( You fixed this one already! -Matt : This occured during low-memory deadlock testing: : :(pageout daemon) : : A blocked malloc in the pageout daemon with a softdep lock : held: : :#2 0xc0238f93 in vm_wait () at ../../vm/vm_page.c:891 :#3 0xc0232d58 in kmem_malloc (map=0xc02db6a0, size=16384, flags=0) :.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 3:41:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C575537B4CF for ; Tue, 7 Nov 2000 03:41:15 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA01397; Tue, 7 Nov 2000 22:31:15 +1100 Date: Tue, 7 Nov 2000 22:31:25 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: source upgrading: bootstrap library In-Reply-To: <3A05DA28.DE3EE486@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Nov 2000, Marcel Moolenaar wrote: > There are multiple ways to solve (avoid) this. One way is is handling > each case seperately, as is currently done for gcc. We build a FreeBSD > specific library for gcc that contains functions we need to be backward > compatible (see /usr/src/gnu/usr.bin/cc/cc_fbsd). We have a similar > problem with libiberty and just recently with perl. > > Another approach is to build a bootstrap library as part of the > bootstrap phase and have it contain any and all functions or > compatibility shims we need to be able to upgrade. All bootstrap, build > and cross- tools are to be linked against this library (in such a way > that existing functions are used). > > I tend to favor the latter and plan to implement it. Let me know if you > have any objections, alternatives, additions or questions. I think I prefer to handle each case separately, at least at first. There is also a problem with header files. E.g., the current mtree can't be compiled under FreeBSD-2.1.5, because the members of struct timespec were didn't have the braindamaged standard spelling in 2.1.5. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 4: 8:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D49E137B479 for ; Tue, 7 Nov 2000 04:08:51 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA03661; Tue, 7 Nov 2000 23:08:35 +1100 Date: Tue, 7 Nov 2000 23:09:00 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: <200011070246.eA72kF271154@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Nov 2000, Matt Dillon wrote: > This occured during low-memory deadlock testing: > > -Matt > > (pageout daemon) > > A blocked malloc in the pageout daemon with a softdep lock > held: > > #2 0xc0238f93 in vm_wait () at ../../vm/vm_page.c:891 > #3 0xc0232d58 in kmem_malloc (map=0xc02db6a0, size=16384, flags=0) > at ../../vm/vm_kern.c:361 > #4 0xc015bb47 in malloc (size=16384, type=0xc02c0c20, flags=0) > at ../../kern/kern_malloc.c:188 > #5 0xc0223321 in softdep_disk_io_initiation (bp=0xcf379220) > at ../../ufs/ffs/ffs_softdep.c:2807 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here > #6 0xc01964c3 in spec_strategy (ap=0xdca8fbdc) > at ../../miscfs/specfs/spec_vnops.c:412 > #7 0xc0195fe1 in spec_vnoperate (ap=0xdca8fbdc) > at ../../miscfs/specfs/spec_vnops.c:117 > #8 0xc022f31d in ufs_vnoperatespec (ap=0xdca8fbdc) > at ../../ufs/ufs/ufs_vnops.c:2303 > #9 0xc022ed55 in ufs_strategy (ap=0xdca8fc20) at vnode_if.h:923 > #10 0xc022f2ed in ufs_vnoperate (ap=0xdca8fc20) > at ../../ufs/ufs/ufs_vnops.c:2285 > #11 0xc018369f in bwrite (bp=0xcf379220) at vnode_if.h:923 > #12 0xc021f3e3 in ffs_balloc (ap=0xdca8fd40) at ../../ufs/ffs/ffs_balloc.c:316 > #13 0xc0228119 in ffs_write (ap=0xdca8fd90) at vnode_if.h:1035 > #14 0xc023d3fb in vnode_pager_generic_putpages (vp=0xe191fd80, m=0xdca8fea0, > > > Caused a panic to occur here in the update daemon: > > #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c) > at ../../ufs/ffs/ffs_softdep.c:262 > #11 0xc02207a6 in softdep_process_worklist (matchmnt=0x0) > at ../../ufs/ffs/ffs_softdep.c:546 > #12 0xc018b26b in sched_sync () at ../../kern/vfs_subr.c:1034 > #13 0xc02542a0 in fork_trampoline () > cannot read proc at 0 > (kgdb) frame 10 > #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c) > at ../../ufs/ffs/ffs_softdep.c:262 > 262 panic("softdep_lock: lock held by %d", lk->lkt_held); > (kgdb) This is fixed in -current: RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v Working file: ffs_softdep.c head: 1.74 ... ---------------------------- revision 1.73 date: 2000/09/07 23:02:55; author: mckusick; state: Exp; lines: +3 -3 Cannot do MALLOC with M_WAITOK while holding ACQUIRE_LOCK Obtained from: Ethan Solomita ---------------------------- ... but I don't see how using malloc() in low-level i/o routines can be safe in general. Deadlock seems to be possible if completion of output is necessary to free some pages. Deadlock just usually doesn't occur, because the system attempts to reserve enough free pages to satisfy low-level memory allocations. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 4:15:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4CA5337B479 for ; Tue, 7 Nov 2000 04:15:30 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA04066; Tue, 7 Nov 2000 23:15:18 +1100 Date: Tue, 7 Nov 2000 23:15:44 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: Whoops, never mind... I see the commit (was Re: softdep panic due to blocked malloc (with traceback)) In-Reply-To: <200011070300.eA730PG71275@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Nov 2000, Matt Dillon wrote: > Bleh. What I get for not updating my cvs tree for a few weeks :-( > > You fixed this one already! > > -Matt > > > : This occured during low-memory deadlock testing: > : > :(pageout daemon) > : > : A blocked malloc in the pageout daemon with a softdep lock > : held: > : > :#2 0xc0238f93 in vm_wait () at ../../vm/vm_page.c:891 > :#3 0xc0232d58 in kmem_malloc (map=0xc02db6a0, size=16384, flags=0) > :.. Still not fixed in RELENG_4 (or RELENG_3, but I guess the fix there is to tell people to upgrade or not use soft updates). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 8: 8:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id BDD1537B4C5 for ; Tue, 7 Nov 2000 08:08:29 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7G8Jb73998; Tue, 7 Nov 2000 08:08:19 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 08:08:19 -0800 (PST) From: Matt Dillon Message-Id: <200011071608.eA7G8Jb73998@earth.backplane.com> To: Bruce Evans Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... but I don't see how using malloc() in low-level i/o routines can be :safe in general. Deadlock seems to be possible if completion of output :is necessary to free some pages. Deadlock just usually doesn't occur, :because the system attempts to reserve enough free pages to satisfy :low-level memory allocations. : :Bruce I have a complete solution to the low-memory deadlock problem under test with Paul Saab, and DG has approved of the idea. As soon as both Paul and My machines survive a night of extreme memory strain I'll make the patches available generally. This is how it works: * The problem we face is that giving certain system processes special allocation privileages DOES NOT WORK, because non-system processes can still block on a low-memory issue while holding a vnode and this will prevent system processes such as pageout from being able to flush any pages associated with that vnode whether they can allocate memory or not. * We remove all contrived 'low memory' limitations from any code which might be called with a locked vnode. Specifically the buffer cache code. - getblk() no longer blocks if it is low on buffers, only if it is out of buffers. - When the buffer cache codes allocates a page, it is allowed to dig into the free memory reserve rather then block. * All kernel MALLOCs called by filesystem support routines such as ffs_inode.c and ffs_softdep.c use M_USE_RESERVE, allowing the kernel malloc to dig into the memory reserve * If we are low on memory, the following occurs: - All major delayed write calls, bdwrite(), are turned into async calls, bawrite(). - brelse() and bqrelse() free clean buffers and their underlying VM pages (VM pages go into the CACHE instead of the INACTIVE queue), recovering resources immediately. This allows us to continue issuing I/O without limitation and yet not run out of memory. - The rest of the system uses the normal allocator flags and will block in a low memory situation. But due to the new method of doing things our paging I/O still operates to free up new memory. The jist of the solution is that I/O is able to continue when you hit v_free_reserved. While the rest of the system shudders, I/O still goes on which means the system can recover. That's it in a nutshell. The patches are modest but not complex... actually fairly straightforward. I haven't dealt with networking/NFS issues yet, but I believe I have the main filesystem and softupdates working under extreme *dirty* mmap and I/O loads. I'll know when Paul gets back to me on the overnight tests he ran. Note that Paul and I have been testing things for a week with things failing within hours usually, so it may not be today. Or it may... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 8:15:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id B33BC37B68D for ; Tue, 7 Nov 2000 08:15:48 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7GFhX74058; Tue, 7 Nov 2000 08:15:43 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 08:15:43 -0800 (PST) From: Matt Dillon Message-Id: <200011071615.eA7GFhX74058@earth.backplane.com> To: Bruce Evans Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: Whoops, never mind... I see the commit (was Re: softdep panic due to blocked malloc (with traceback)) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Still not fixed in RELENG_4 (or RELENG_3, but I guess the fix there is :to tell people to upgrade or not use soft updates). : :Bruce I think Kirk just forgot. Jordan's given me permission to MFC it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 10: 0:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 61F3537B4D7 for ; Tue, 7 Nov 2000 10:00:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1000) id B51D52B279; Tue, 7 Nov 2000 12:00:05 -0600 (CST) Date: Tue, 7 Nov 2000 10:00:05 -0800 From: Paul Saab To: Matt Dillon Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <20001107100005.A15555@elvis.mu.org> References: <200011071608.eA7G8Jb73998@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011071608.eA7G8Jb73998@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Nov 07, 2000 at 08:08:19AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon (dillon@earth.backplane.com) wrote: > That's it in a nutshell. The patches are modest but not complex... > actually fairly straightforward. I haven't dealt with networking/NFS > issues yet, but I believe I have the main filesystem and softupdates > working under extreme *dirty* mmap and I/O loads. I'll know when Paul > gets back to me on the overnight tests he ran. Note that Paul and I > have been testing things for a week with things failing within hours > usually, so it may not be today. Or it may... So far so good. Usually I could lockup a machine in 5-10 minutes.. Its been 9 hours now and my test machines are still up. yay! -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 10:54:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 62FE537B479 for ; Tue, 7 Nov 2000 10:54:19 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 435BBAEC; Tue, 7 Nov 2000 10:54:13 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA08588; Tue, 7 Nov 2000 10:54:12 -0800 (PST) Message-ID: <3A084FCF.5183DEE9@cup.hp.com> Date: Tue, 07 Nov 2000 13:54:07 -0500 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: source upgrading: bootstrap library References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > > I tend to favor the latter and plan to implement it. Let me know if you > > have any objections, alternatives, additions or questions. > > I think I prefer to handle each case separately, at least at first. Can you elaborate? > There is also a problem with header files. E.g., the current mtree can't > be compiled under FreeBSD-2.1.5, because the members of struct timespec > were didn't have the braindamaged standard spelling in 2.1.5. Does this only occur on pre-2.2 systems? If so, I suggest to delay the issue (or ignore it completely) until after we can upgrade from at least 2.2.5. Any older versions have the make problem and I think that makes a nice barrier. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:12:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 2CB1D37B479 for ; Tue, 7 Nov 2000 11:12:49 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7ICrD25671; Tue, 7 Nov 2000 19:12:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 08:08:19 PST." <200011071608.eA7G8Jb73998@earth.backplane.com> Date: Tue, 07 Nov 2000 19:12:53 +0100 Message-ID: <25669.973620773@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011071608.eA7G8Jb73998@earth.backplane.com>, Matt Dillon writes: > I have a complete solution to the low-memory deadlock problem under > test with Paul Saab, and DG has approved of the idea. As soon as both > Paul and My machines survive a night of extreme memory strain I'll > make the patches available generally. Could we please have an eventhandler chain which gets called when we are short of KVM ? There are code which can free KVM with no significant loss of anything but performance, if only we bother to tell it to do so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:25:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 0448B37B4C5 for ; Tue, 7 Nov 2000 11:25:28 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7JNN881648; Tue, 7 Nov 2000 11:23:23 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 11:23:23 -0800 (PST) From: Matt Dillon Message-Id: <200011071923.eA7JNN881648@earth.backplane.com> To: Poul-Henning Kamp Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <25669.973620773@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Could we please have an eventhandler chain which gets called when :we are short of KVM ? There are code which can free KVM with no :significant loss of anything but performance, if only we bother to :tell it to do so. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 I don't think garbage collection is the answer, because there is always the possibility that there may not be sufficient garbage to collect. Resources have to be managed more actively and in such a way as to allow the system to recover from a severe memory shortage. What this comes down to is that the I/O chain needs to be able to operate 'continuously' in a restricted memory environment. Accomplishing this is extremely easy for the I/O chain -- one simply does not do any delayed-writes and one simply returns resources when one is through with them rather then trying to cache them. As long as the I/O chain continues to operate, the rest of the system can block, and recover, without creating a deadlock situation. It could be argued that garbage collection has already been tried and found to be wanting. The pmap subsystem tries to garbage-collect page table pages already, and the results are not encouraging at all - it's a performance headache plus it cannot guarentee that anything will be returned to the system anyway. In fact, in low-memory situations the pmap garbage collection doesn't help the pagedaemon at all. It frees up some pages and the system then proceeds to eat those up and run out of memory again. The system will still run out of memory. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:27:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 2A16637B479 for ; Tue, 7 Nov 2000 11:27:12 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7JQuD26298; Tue, 7 Nov 2000 20:26:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 11:23:23 PST." <200011071923.eA7JNN881648@earth.backplane.com> Date: Tue, 07 Nov 2000 20:26:56 +0100 Message-ID: <26296.973625216@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011071923.eA7JNN881648@earth.backplane.com>, Matt Dillon writes: >:Could we please have an eventhandler chain which gets called when >:we are short of KVM ? There are code which can free KVM with no >:significant loss of anything but performance, if only we bother to >:tell it to do so. >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >:phk@FreeBSD.ORG | TCP/IP since RFC 956 > > I don't think garbage collection is the answer, because there is always > the possibility that there may not be sufficient garbage to collect. We are not talking garbage collection, we are talking dumping the vfs namecache for instance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:44:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 11A3A37B479 for ; Tue, 7 Nov 2000 11:44:14 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7JfZX81819; Tue, 7 Nov 2000 11:41:35 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 11:41:35 -0800 (PST) From: Matt Dillon Message-Id: <200011071941.eA7JfZX81819@earth.backplane.com> To: Poul-Henning Kamp Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <26296.973625216@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :We are not talking garbage collection, we are talking dumping the :vfs namecache for instance. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Yes, but think a minute: How does that prevent a low memory deadlock? The answer is not "because it frees up some pages" ... what if you've already freed up all the namecache pages you can and some process continues to eat memory, and now you have none left to free? The issue is how to avoid a memory deadlock. The problem with freeing cache resources is that it doesn't help you avoid a memory deadlock. If someone immediately reallocates the memory for another purpose -- and dirties it so it can't be freed again. To avoid a memory deadlock you have to manage the processes doing the allocations during the low-memory situation, not the people who already have it in caches. In the case of the I/O subsystem, this management takes the form: The I/O system must be able to work in a low-memory situation, so we manage it by immediately freeing (recycling) resources used in the I/O during the low-memory situation rather then blocking the I/O. Because the I/O subsystem is now well behaved, we can allow it to eat into the system memory reserve because we know it will not exhaust the reserve. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:50:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 72CF037B4D7 for ; Tue, 7 Nov 2000 11:50:01 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7JnjD26626; Tue, 7 Nov 2000 20:49:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 11:41:35 PST." <200011071941.eA7JfZX81819@earth.backplane.com> Date: Tue, 07 Nov 2000 20:49:45 +0100 Message-ID: <26624.973626585@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011071941.eA7JfZX81819@earth.backplane.com>, Matt Dillon writes: >:We are not talking garbage collection, we are talking dumping the >:vfs namecache for instance. >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > Yes, but think a minute: How does that prevent a low memory deadlock? > The answer is not "because it frees up some pages" ... what if you've > already freed up all the namecache pages you can and some process > continues to eat memory, and now you have none left to free? Matt, I'll just rest the case here. I can see from the swiftness of your replies that you are in "everything phk says is wrong by definition" mode right now. Think about it and we can discuss it in a couple of weeks time maybe. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 11:56:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 5F9FD37B4CF for ; Tue, 7 Nov 2000 11:56:33 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7Jrx081934; Tue, 7 Nov 2000 11:53:59 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 11:53:59 -0800 (PST) From: Matt Dillon Message-Id: <200011071953.eA7Jrx081934@earth.backplane.com> To: Poul-Henning Kamp Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <26624.973626585@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'll just rest the case here. I can see from the swiftness of your :replies that you are in "everything phk says is wrong by definition" :mode right now. Think about it and we can discuss it in a couple :of weeks time maybe. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Poul. Paul and I have been working on low-memory deadlocks for the past week. I've easily spent 50 hours working on it and Paul has probably spent closer to 100 hours. You don't have to believe me if you don't want to. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 12: 8:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2F66937B4C5 for ; Tue, 7 Nov 2000 12:08:36 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA125600; Tue, 7 Nov 2000 15:05:36 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <25669.973620773@critter> References: <25669.973620773@critter> Date: Tue, 7 Nov 2000 15:05:34 -0500 To: Poul-Henning Kamp , Matt Dillon From: Garance A Drosihn Subject: Re: softdep panic due to blocked malloc (with traceback) Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 7:12 PM +0100 11/7/00, Poul-Henning Kamp wrote: >Matt Dillon writes: > > > I have a complete solution to the low-memory deadlock problem > > under test with Paul Saab, and DG has approved of the idea. As > > soon as both Paul and My machines survive a night of extreme > > memory strain I'll make the patches available generally. > >Could we please have an eventhandler chain which gets called when >we are short of KVM ? There are code which can free KVM with no >significant loss of anything but performance, if only we bother to >tell it to do so. Do you mean something like the SIGDANGER signal, which is available under aix? (I'm just wondering) -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 12:23:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 6D81C37B4C5 for ; Tue, 7 Nov 2000 12:23:45 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA7KLKa57382; Tue, 7 Nov 2000 13:21:21 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011072021.eA7KLKa57382@aslan.scsiguy.com> To: Matt Dillon Cc: Poul-Henning Kamp , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 11:53:59 PST." <200011071953.eA7Jrx081934@earth.backplane.com> Date: Tue, 07 Nov 2000 13:21:20 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Poul. Paul and I have been working on low-memory deadlocks for the past > week. I've easily spent 50 hours working on it and Paul has probably > spent closer to 100 hours. You don't have to believe me if you don't want > to. > > -Matt That's not what Poul-Henning was attempting to convey. If you are near the edge, you need to make sure you don't fall off the edge. That is the jist of your changes. Poul-Henning's request was for a facility to possibly give you more space near the edge to work your way away from it. In otherwords, you might thrash less or recover more quickly from a low memory situation if you tell the rest of the kernel to free up data that can be recreated on demand. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 12:48:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (unknown [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 2B50837B479 for ; Tue, 7 Nov 2000 12:48:16 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VT2YDX3A; Tue, 7 Nov 2000 15:48:23 -0500 Reply-To: Randell Jesup To: "Justin T. Gibbs" Cc: Matt Dillon , Poul-Henning Kamp , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <200011072021.eA7KLKa57382@aslan.scsiguy.com> From: Randell Jesup Date: 07 Nov 2000 15:52:35 -0500 In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 07 Nov 2000 13:21:20 -0700" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: >That's not what Poul-Henning was attempting to convey. If you are near the >edge, you need to make sure you don't fall off the edge. That is >the jist of your changes. Poul-Henning's request was for a facility >to possibly give you more space near the edge to work your way away >from it. In otherwords, you might thrash less or recover more quickly >from a low memory situation if you tell the rest of the kernel to free >up data that can be recreated on demand. I think both Matt's changes and what Poul-Henning can be useful. (Actually, it sounds like Matt's are required, and Poul-Henning's might be nice if and when someone does them). IMHO -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 13:22:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 391B137B4C5 for ; Tue, 7 Nov 2000 13:22:12 -0800 (PST) Received: from pretoria-57.budapest.interware.hu ([195.70.53.121] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13tGBi-0003eF-00; Tue, 07 Nov 2000 22:21:50 +0100 Message-ID: <3A087257.DBA40791@elischer.org> Date: Tue, 07 Nov 2000 13:21:27 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Randell Jesup Cc: "Justin T. Gibbs" , Matt Dillon , Poul-Henning Kamp , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <200011072021.eA7KLKa57382@aslan.scsiguy.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Randell Jesup wrote: > > "Justin T. Gibbs" writes: > >That's not what Poul-Henning was attempting to convey. If you are near the > >edge, you need to make sure you don't fall off the edge. That is > >the jist of your changes. Poul-Henning's request was for a facility > >to possibly give you more space near the edge to work your way away > >from it. In otherwords, you might thrash less or recover more quickly > >from a low memory situation if you tell the rest of the kernel to free > >up data that can be recreated on demand. > > I think both Matt's changes and what Poul-Henning can be useful. > (Actually, it sounds like Matt's are required, and Poul-Henning's might be > nice if and when someone does them). I think that they are talking with cross purposes.. Matt is right that nothing that magically comes up with a few hundred KB of ram can be guaranteed to stop a deadlock, because after the few hundred KB have been used up, If the big memory hog keeps eating memory, you are right back where you started, and you no longer have a few hundred KB up your sleeve. On the other hand, PHK is correct in that it would be a useful facility to have and that it might buy some breathing space. To be ueful however I think it would need to be combined with some other measures to ensure that we don't get straight back into debt. For example triggering that queue might change the strategies in the kernel so that the biggest memory users are forced to start losing pages. (e.g. it's swapped out) or some similar work.. > > IMHO > > -- > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > rjesup@wgate.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 13:41:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 6EB3337B479 for ; Tue, 7 Nov 2000 13:41:46 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7Lf2D27540; Tue, 7 Nov 2000 22:41:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 15:05:34 EST." Date: Tue, 07 Nov 2000 22:41:02 +0100 Message-ID: <27538.973633262@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >At 7:12 PM +0100 11/7/00, Poul-Henning Kamp wrote: >>Matt Dillon writes: >> >> > I have a complete solution to the low-memory deadlock problem >> > under test with Paul Saab, and DG has approved of the idea. As >> > soon as both Paul and My machines survive a night of extreme >> > memory strain I'll make the patches available generally. >> >>Could we please have an eventhandler chain which gets called when >>we are short of KVM ? There are code which can free KVM with no >>significant loss of anything but performance, if only we bother to >>tell it to do so. > >Do you mean something like the SIGDANGER signal, which is available >under aix? (I'm just wondering) That too might be a very good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 13:55:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1CE2637B4D7 for ; Tue, 7 Nov 2000 13:55:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7LrB982768; Tue, 7 Nov 2000 13:53:11 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 13:53:11 -0800 (PST) From: Matt Dillon Message-Id: <200011072153.eA7LrB982768@earth.backplane.com> To: Poul-Henning Kamp Cc: Garance A Drosihn , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <27538.973633262@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>>we are short of KVM ? There are code which can free KVM with no :>>significant loss of anything but performance, if only we bother to :>>tell it to do so. There is absolutely no correlation, none whatsoever, between memory load and the amount of KVM the system is using. Zero. Zip. Nada. Trying to tie the two together is a complete waste of time. KVM utilization should be self regulating, but if you try to do something 'special' in low memory situations you will screw yourself badly ... you will make a system that is already inefficient from the load even more inefficient and less able to recover. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14: 2: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 306CE37B479 for ; Tue, 7 Nov 2000 14:02:07 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA00641; Tue, 7 Nov 2000 13:59:34 -0800 (PST) Message-Id: <200011072159.NAA00641@implode.root.com> To: Poul-Henning Kamp Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-reply-to: Your message of "Tue, 07 Nov 2000 20:49:45 +0100." <26624.973626585@critter> From: David Greenman Reply-To: dg@root.com Date: Tue, 07 Nov 2000 13:59:34 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >In message <200011071941.eA7JfZX81819@earth.backplane.com>, Matt Dillon writes: >>:We are not talking garbage collection, we are talking dumping the >>:vfs namecache for instance. >>: >>:-- >>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> >> Yes, but think a minute: How does that prevent a low memory deadlock? >> The answer is not "because it frees up some pages" ... what if you've >> already freed up all the namecache pages you can and some process >> continues to eat memory, and now you have none left to free? > >Matt, > >I'll just rest the case here. I can see from the swiftness of your >replies that you are in "everything phk says is wrong by definition" >mode right now. Think about it and we can discuss it in a couple >of weeks time maybe. Actually, I think Matt is entirely correct and his approach is the only one that can effectively deal with low memory deadlocks. Basically, the I/O system and the VM system need to be able to operate when memory is transiently tight so that they are able to make more space available. Clearing out caches isn't going to solve the problem for the reasons Matt already pointed out - you can't be assured that enough cache pages will be available to resolve the problem. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14: 4:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id CF7D337B479 for ; Tue, 7 Nov 2000 14:04:45 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA00682; Tue, 7 Nov 2000 14:04:00 -0800 (PST) Message-Id: <200011072204.OAA00682@implode.root.com> To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-reply-to: Your message of "Tue, 07 Nov 2000 13:21:27 PST." <3A087257.DBA40791@elischer.org> From: David Greenman Reply-To: dg@root.com Date: Tue, 07 Nov 2000 14:04:00 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I think both Matt's changes and what Poul-Henning can be useful. >> (Actually, it sounds like Matt's are required, and Poul-Henning's might be >> nice if and when someone does them). > >I think that they are talking with cross purposes.. > >Matt is right that nothing that magically comes up with a few hundred KB >of ram >can be guaranteed to stop a deadlock, because after the few hundred KB >have been >used up, If the big memory hog keeps eating memory, you are right back >where you >started, and you no longer have a few hundred KB up your sleeve. > >On the other hand, PHK is correct in that it would be a useful facility >to have and that it might buy some breathing space. To be ueful however >I think it >would need to be combined with some other measures to ensure that we >don't get straight >back into debt. For example triggering that queue might change the >strategies in the >kernel so that the biggest memory users are forced to start losing >pages. >(e.g. it's swapped out) or some similar work.. The problem with this line of thinking is that transient memory shortages happen all the time in normal operation of the system and one definately doesn't want to be flushing the cache in these cases - that just makes the system slower and even less responsive. I really think that cache flushing is a non-starter solution for any problem (other than cache coherency issues). -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14:20: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id ED79637B479 for ; Tue, 7 Nov 2000 14:19:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7MI5w83049; Tue, 7 Nov 2000 14:18:05 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 14:18:05 -0800 (PST) From: Matt Dillon Message-Id: <200011072218.eA7MI5w83049@earth.backplane.com> To: David Greenman Cc: Poul-Henning Kamp , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <200011072159.NAA00641@implode.root.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok guys... I'll apologize here for tying these two things together. I really thought Poul was talking about his idea in the context of an extreme low-memory situation. That said, however, I must still disagree with the concept. I think KVM needs to be managed actively, not randomly from third party routine(s) deciding they wants 'general' KVM subsystems to clear out some memory. For example, take the vnode/inode cache ... the only subsystem that really knows how to manage the vnode/inode cache is the vnode/inode subsystem. If it doesn't know how to manage the cache, then certainly no third party routine outside that subsystem which decides to call the cleanup chain will know! Even if taken only as a hint, its a hint given by a third party routine which has no clue about the vnode/inode cache or any other cache. It's a worthless hint. There is no such thing as 'potential breathing room' in an extreme low-memory situation. There is only what you can guarentee, and the only thing you can guarentee is managed control over the last vm.v_free_reserved pages of memory. You guarentee the managed control by guarenteeing that the only subsystems allowed to allocate from that pool know how to release their resources in real time (allocate, perform function, release) when faced with extreme low-memory situations. The memhog3.c program, for example, can allocate and DIRTY *hundreds* of megabytes in less then a second. Hundreds! No cleanup chain could ever hope to compete against that. Perhaps what we really need is some sort of wakeup chain, something that runs once a second or 5 times a second or something like that which could call a chain of management routines every so often (rather then having to create kernel threads which sleep on lbolt for each subsystem). These cleanup routines would be charged with the duty of maintaining their respective caches, *not* flushing them, and would not be allowed to block. Maintainance rather then flushing... I think something like that could be beneficial. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14:21:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 675C337B479 for ; Tue, 7 Nov 2000 14:21:46 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7MLkD28043 for ; Tue, 7 Nov 2000 23:21:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: Green/Yellow/Red state for the VM system. From: Poul-Henning Kamp Date: Tue, 07 Nov 2000 23:21:46 +0100 Message-ID: <28041.973635706@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Varios people have heard about this in private conversations before, so it's probably time for me to pull the plug and plug it publically. To all of you northern californians, this proposal should come as nothing new at all, you've seen your electrical grid do this again this summer: You cut some load entirely in order to keep the majority of the grid intact. We need to do the same thing about resource-shortages in the kernel. The easiest way to deal with overload and DoS attacks is to recognize them as such, go into defensive mode and weather it. If we implement a generic facility for this, we will have a lot less worries about future DoS attacks, because our generic mechanism will deal with a lot of them on its own. The facility I hinted at in an earlier email is this: The VM system maintains an enum variables: enum {GREEN, YELLOW, RED} kvm_light; When kvm_light changes value, a kernel event-handler list is activiated. GREEN means "No worries". And signals that all kernel code can go about their business as usual. YELLOW means "Don't make it any worse". This state is set as a high water mark, and tries to prevent us from ever entering: RED which means "Disaster on our hands.". Various pieces of code can use these state changes to modify their behaviour according to the state of the kvm_light. Here are some straw-man examples, just to show the concept: vfs_name_cache: Yellow: Drop two entries every time we make one. Red: Drop all entries, make no new ones. Vnode system: Yellow: Allocate no new vnodes. Red: Garbage collect and free vnodes. (yes, this *is* possible, but only as a last resort thing.) IP: Yellow: Expire cloned routes faster. Stop generating ICMP packets. Stop forwarding packets. Red: Expire all cloned routes now. TCP: Yellow: Accept no new TCP connections. Reduce outgoing TCP windows. Drop all sessions which have not passed a packet in the last N seconds. Red: Drop all un-assembled fragments. Drop all "final-stages" TCP pcbs. Drop all sessions which have not passed a packet in the last M seconds. (M << N) Now, before anyone starts point indignated fingers in RFC's and other such moral high-ground, let me just make it perfectly clear that YELLOW isn't set until the system detects the risk of meltdown and RED is the meltdown. Think of YELLOW as being set a little while before you cannot log into the console in finite time anymore and usually decide to give the machine a reboot/reset to get it back into action. RED is when the machine would normally wedge solid or panic. As can be seen from the above, the only and entire impact on the VM system is to maintain the kvm_light variable and call the eventahandler when it is changed. The rest of this is about getting individual parts of the kernel to behave more responsible in YELLOW, and to start pumping water all they can in RED. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14:51: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 56B6F37B479; Tue, 7 Nov 2000 14:50:57 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA52720; Tue, 7 Nov 2000 23:50:56 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> From: Dag-Erling Smorgrav Date: 07 Nov 2000 23:50:55 +0100 In-Reply-To: Poul-Henning Kamp's message of "Tue, 07 Nov 2000 23:21:46 +0100" Message-ID: Lines: 47 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > IP: > Yellow: > Expire cloned routes faster. > Stop generating ICMP packets. > Stop forwarding packets. + Stop passing packets to bpf (which IIRC needs to duplicate them, which eats mbufs) > Red: > Expire all cloned routes now. + If running dummynet, drop everything that enters a pipe as if that pipe was full. > TCP: > Yellow: > Accept no new TCP connections. > Reduce outgoing TCP windows. > Drop all sessions which have not passed > a packet in the last N seconds. > > Red: > Drop all un-assembled fragments. > Drop all "final-stages" TCP pcbs. (i.e. CLOSING, FIN_WAIT_1, FIN_WAIT_2 or TIME_WAIT) > Drop all sessions which have not passed > a packet in the last M seconds. (M << N) + Drop connections that are in SYN_RECEIVED state > Now, before anyone starts point indignated fingers in RFC's and > other such moral high-ground, let me just make it perfectly clear > that YELLOW isn't set until the system detects the risk of meltdown > and RED is the meltdown. Personally, if violating an RFC can keep my server from panicking when attacked, then the RFC can go take a hike (as I think I've already demonstrated with TCP_RESTRICT_RST and TCP_DROP_SYNFIN) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 14:58:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1B27E37B4C5; Tue, 7 Nov 2000 14:58:56 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA52800; Tue, 7 Nov 2000 23:58:54 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> From: Dag-Erling Smorgrav Date: 07 Nov 2000 23:58:53 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "07 Nov 2000 23:50:55 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Poul-Henning Kamp writes: > > IP: > > Red: > > Expire all cloned routes now. > > + If running dummynet, drop everything that enters a > pipe as if that pipe was full. Oh, and stop creating new dynamic ipfw rules if using stateful inspection. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:15:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id F1D4B37B6C3 for ; Tue, 7 Nov 2000 15:15:43 -0800 (PST) Received: (qmail 81029 invoked from network); 7 Nov 2000 23:14:11 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 Nov 2000 23:14:11 -0000 Message-ID: <3A088D1B.96157C0D@telehouse.ch> Date: Wed, 08 Nov 2000 00:15:39 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't think this is necessary at all after Matt's and Paul's code being commited. Why? Because the box would not wedge solid or panic anymore. Also, what point does it make to free up some KVM space if some user- land app is going crazy? As far as I know there is no dynamic sharing of KVM/User memory. The (no longer) problem you try to solve here would have been a hack to work around dead-locking due to 'bad' code-paths in the VM-I/O system until the real fix (fixing dead-locks) can be made. Now that fix to avoid dead-locking has been made and is under testing. This obsoletes your here proposed VM emergency states entierly. The only optimizations IMO that would make sense would be only local to a sub-system. Lets take the IP route code as an example. The moment it see's getting problems allocating more space for new route entries it would early-expire the cloned entries to make room for new ones. In no case it would ever stop forwarding packets. This would lead to non-determistic behaviour and making DoS attacks easy and the figuring out why-the-heck-this-god-damn-system-isn't-forwarding-any-packets-any- more *really* hard. Instead the right fix would be to use something like RED or BLUE to drop packets like we do on any overloaded link except in this case it's the system itself which is the bottlenck. To summarize: 1) IMO your approach here is very flawed and the wrong solution to the right problem 2) any detection of low-KVM situations should be done on a sub-system level and handled in-the-right-way on a local sub-system basis not on a global basis 3) IMO the actions you propose are not-the-right-thing most of the time, especially in the IP and TCP cases my 2c -- Andre Poul-Henning Kamp wrote: > > Varios people have heard about this in private conversations before, > so it's probably time for me to pull the plug and plug it publically. > > To all of you northern californians, this proposal should come as > nothing new at all, you've seen your electrical grid do this again > this summer: You cut some load entirely in order to keep the > majority of the grid intact. > > We need to do the same thing about resource-shortages in the kernel. > > The easiest way to deal with overload and DoS attacks is to recognize > them as such, go into defensive mode and weather it. > > If we implement a generic facility for this, we will have a lot less > worries about future DoS attacks, because our generic mechanism will > deal with a lot of them on its own. > > The facility I hinted at in an earlier email is this: > > The VM system maintains an enum variables: > > enum {GREEN, YELLOW, RED} kvm_light; > > When kvm_light changes value, a kernel event-handler list is activiated. > > GREEN means "No worries". And signals that all kernel code can go > about their business as usual. > > YELLOW means "Don't make it any worse". This state is set as a high > water mark, and tries to prevent us from ever entering: > > RED which means "Disaster on our hands.". > > Various pieces of code can use these state changes to modify their > behaviour according to the state of the kvm_light. Here are > some straw-man examples, just to show the concept: > > vfs_name_cache: > > Yellow: > Drop two entries every time we make one. > > Red: > Drop all entries, make no new ones. > > Vnode system: > > Yellow: > Allocate no new vnodes. > > Red: > Garbage collect and free vnodes. > (yes, this *is* possible, but only as a last resort thing.) > > IP: > Yellow: > Expire cloned routes faster. > Stop generating ICMP packets. > Stop forwarding packets. > > Red: > Expire all cloned routes now. > > TCP: > Yellow: > Accept no new TCP connections. > Reduce outgoing TCP windows. > Drop all sessions which have not passed > a packet in the last N seconds. > > Red: > Drop all un-assembled fragments. > Drop all "final-stages" TCP pcbs. > Drop all sessions which have not passed > a packet in the last M seconds. (M << N) > > Now, before anyone starts point indignated fingers in RFC's and > other such moral high-ground, let me just make it perfectly clear > that YELLOW isn't set until the system detects the risk of meltdown > and RED is the meltdown. > > Think of YELLOW as being set a little while before you cannot log > into the console in finite time anymore and usually decide to give > the machine a reboot/reset to get it back into action. > > RED is when the machine would normally wedge solid or panic. > > As can be seen from the above, the only and entire impact on the > VM system is to maintain the kvm_light variable and call the > eventahandler when it is changed. The rest of this is about getting > individual parts of the kernel to behave more responsible in YELLOW, > and to start pumping water all they can in RED. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:30:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0873637B479 for ; Tue, 7 Nov 2000 15:30:48 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA7NSbU13782; Tue, 7 Nov 2000 15:28:37 -0800 (PST) Date: Tue, 7 Nov 2000 15:28:37 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <20001107152836.I5112@fw.wintelcom.net> References: <200011071608.eA7G8Jb73998@earth.backplane.com> <25669.973620773@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <25669.973620773@critter>; from phk@critter.freebsd.dk on Tue, Nov 07, 2000 at 07:12:53PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [001107 11:12] wrote: > In message <200011071608.eA7G8Jb73998@earth.backplane.com>, Matt Dillon writes: > > > I have a complete solution to the low-memory deadlock problem under > > test with Paul Saab, and DG has approved of the idea. As soon as both > > Paul and My machines survive a night of extreme memory strain I'll > > make the patches available generally. > > Could we please have an eventhandler chain which gets called when > we are short of KVM ? There are code which can free KVM with no > significant loss of anything but performance, if only we bother to > tell it to do so. Wait a second, didn't you argue against doing this when I proposed it nearly a year ago? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:33:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id A3A6937B479; Tue, 7 Nov 2000 15:33:49 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1000) id 1ADEE2B294; Tue, 7 Nov 2000 17:33:44 -0600 (CST) Date: Tue, 7 Nov 2000 15:33:43 -0800 From: Paul Saab To: Andre Oppermann Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <20001107153343.A24788@elvis.mu.org> References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A088D1B.96157C0D@telehouse.ch>; from oppermann@telehouse.ch on Wed, Nov 08, 2000 at 12:15:39AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andre Oppermann (oppermann@telehouse.ch) wrote: > > I don't think this is necessary at all after Matt's and Paul's code > being commited. Why? Because the box would not wedge solid or panic > anymore. I wouldn't make such a bold statement.. We find all sorts of interesting bugs on a daily basis and I would bet money we'll find another way to lockup the system. -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:39:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 7498037B4CF for ; Tue, 7 Nov 2000 15:39:40 -0800 (PST) Received: (qmail 83541 invoked from network); 7 Nov 2000 23:38:08 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 Nov 2000 23:38:08 -0000 Message-ID: <3A0892BB.4F399708@telehouse.ch> Date: Wed, 08 Nov 2000 00:39:39 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Saab Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Paul Saab wrote: > > Andre Oppermann (oppermann@telehouse.ch) wrote: > > > > I don't think this is necessary at all after Matt's and Paul's code > > being commited. Why? Because the box would not wedge solid or panic > > anymore. > > I wouldn't make such a bold statement.. We find all sorts of interesting > bugs on a daily basis and I would bet money we'll find another way to > lockup the system. OK, but would the right solution be to simply make more memory available? I doubt it. A bug is a bug and needs to be fixed not to be masked. Eventually it would fail just in a different place. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:48:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 36BE137B479 for ; Tue, 7 Nov 2000 15:48:29 -0800 (PST) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 56D5449; Tue, 7 Nov 2000 19:48:27 -0400 (AST) Message-ID: <3A0894CB.126EE64E@vangelderen.org> Date: Tue, 07 Nov 2000 19:48:27 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <26624.973626585@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <200011071941.eA7JfZX81819@earth.backplane.com>, Matt Dillon writes: > >:We are not talking garbage collection, we are talking dumping the > >:vfs namecache for instance. > >: > >:-- > >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > > > Yes, but think a minute: How does that prevent a low memory deadlock? > > The answer is not "because it frees up some pages" ... what if you've > > already freed up all the namecache pages you can and some process > > continues to eat memory, and now you have none left to free? > > Matt, > > I'll just rest the case here. I can see from the swiftness of your > replies that you are in "everything phk says is wrong by definition" > mode right now. Think about it and we can discuss it in a couple > of weeks time maybe. It seems that Matt simply assumes that the event handler chain was proposed to help in the prevention of system deadlock. Given this context he argues that it won't help solve the problem (deadlock) he is trying to solve. I think Matt may have misinterpreted your initial request for a 'the event handler chain is needed to solve the problem' instead of a 'nice-to-have-an-event-handler' request. His fault, maybe... Of course, given the history the two of you have, you could have pro-actively elaborated a bit in your request so as to prevent this kind of miscommunication altogether. You didn't, no problem because: You could have extracted Matts wrong assumption from his subsequent emails (it's quite blatantly obvious) and rectified it thereby preventing this escalation altogether. You choose to not do so and for that reason Matt continues to argue that the even handlers won't help preventing system deadlock. He is quite correct. I can't see how the swiftness of his replies would neccessarily indicate that Matt is in 'everything phk says is wrong..."-mode. And even if he is, you could have steered the discussion in a more productive direction. Come to think of it, I actually think it's the other way around here: had you been slightly less swift in sending <26296.973625216@critter> you could have actually elaborated a bit about the reasoning behind your request (i.e. write more than two lines in that email) and have prevented this escalation. I think you switched to "whatever Matt mails he is always in "everything phk says is wrong by definition""-mode and you are blaming Matt for that. The pot calling the kettle black? -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:48:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 2E19C37B4CF; Tue, 7 Nov 2000 15:48:34 -0800 (PST) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 641851C83; Tue, 7 Nov 2000 18:48:33 -0500 (EST) Date: Tue, 7 Nov 2000 18:48:33 -0500 From: Bill Fumerola To: Andre Oppermann Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <20001107184833.W37870@jade.chc-chimes.com> References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A088D1B.96157C0D@telehouse.ch>; from oppermann@telehouse.ch on Wed, Nov 08, 2000 at 12:15:39AM +0100 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 08, 2000 at 12:15:39AM +0100, Andre Oppermann wrote: > > I don't think this is necessary at all after Matt's and Paul's code > being commited. Why? Because the box would not wedge solid or panic > anymore. I stopped reading here because you obviously didn't read phk's entire post and the reasons behind it. The idea is more general purpose for the system, not for some specific problem. I've been a long fan of the proposal (from when phk hinted at it before), and I'd be one of the first to go implement the appropriate actions for yellow/red in netinet/* as I found time to do so. -- Bill Fumerola - Lame Duck, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:49:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 6D67D37B479; Tue, 7 Nov 2000 15:49:41 -0800 (PST) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 0EFBD1C83; Tue, 7 Nov 2000 18:49:41 -0500 (EST) Date: Tue, 7 Nov 2000 18:49:41 -0500 From: Bill Fumerola To: Andre Oppermann Cc: Paul Saab , Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <20001107184940.X37870@jade.chc-chimes.com> References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> <3A0892BB.4F399708@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A0892BB.4F399708@telehouse.ch>; from oppermann@telehouse.ch on Wed, Nov 08, 2000 at 12:39:39AM +0100 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 08, 2000 at 12:39:39AM +0100, Andre Oppermann wrote: > OK, but would the right solution be to simply make more memory > available? I doubt it. A bug is a bug and needs to be fixed not > to be masked. Eventually it would fail just in a different place. When you are being attacked / loosing resources to some big problem, any memory you make available is going to be eaten by the bug / attack. The trick is to change your behavior, not just use a bigger tool. -- Bill Fumerola - Lame Duck, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 15:57:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id A4AF637B4C5 for ; Tue, 7 Nov 2000 15:57:36 -0800 (PST) Received: (qmail 85400 invoked from network); 7 Nov 2000 23:56:01 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 Nov 2000 23:56:01 -0000 Message-ID: <3A0896EC.A2CA3106@telehouse.ch> Date: Wed, 08 Nov 2000 00:57:32 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Paul Saab , Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> <3A0892BB.4F399708@telehouse.ch> <20001107184940.X37870@jade.chc-chimes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Wed, Nov 08, 2000 at 12:39:39AM +0100, Andre Oppermann wrote: > > > OK, but would the right solution be to simply make more memory > > available? I doubt it. A bug is a bug and needs to be fixed not > > to be masked. Eventually it would fail just in a different place. > > When you are being attacked / loosing resources to some big problem, > any memory you make available is going to be eaten by the bug / attack. > > The trick is to change your behavior, not just use a bigger tool. If you had read my previous email further, instead of just stopping after the first sentence that apparently offended you, you would have seen that I come to the same conclusion with the twist that the change of behaviour should happen on a per sub-system basis, not on a global kernel-KVM basis. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 16:27:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 2719137B4C5; Tue, 7 Nov 2000 16:27:55 -0800 (PST) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 99AD51C75; Tue, 7 Nov 2000 19:27:54 -0500 (EST) Date: Tue, 7 Nov 2000 19:27:54 -0500 From: Bill Fumerola To: Andre Oppermann Cc: Paul Saab , Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <20001107192754.Y37870@jade.chc-chimes.com> References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> <3A0892BB.4F399708@telehouse.ch> <20001107184940.X37870@jade.chc-chimes.com> <3A0896EC.A2CA3106@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A0896EC.A2CA3106@telehouse.ch>; from oppermann@telehouse.ch on Wed, Nov 08, 2000 at 12:57:32AM +0100 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 08, 2000 at 12:57:32AM +0100, Andre Oppermann wrote: > If you had read my previous email further, instead of just stopping > after the first sentence that apparently offended you, you would have > seen that I come to the same conclusion with the twist that the change > of behaviour should happen on a per sub-system basis, not on a global > kernel-KVM basis. I think that a subsystem variable could have value, but there are portions of the kernel that an attack on one subsystem has a large effect on others. -- Bill Fumerola - Lame Duck, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 17: 8:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 4DEBB37B479 for ; Tue, 7 Nov 2000 17:08:33 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA17607; Tue, 7 Nov 2000 18:06:35 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAm_aySD; Tue Nov 7 18:01:23 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA01102; Tue, 7 Nov 2000 18:02:56 -0700 (MST) From: Terry Lambert Message-Id: <200011080102.SAA01102@usr08.primenet.com> Subject: Re: softdep panic due to blocked malloc (with traceback) To: julian@elischer.org (Julian Elischer) Date: Wed, 8 Nov 2000 01:02:56 +0000 (GMT) Cc: rjesup@wgate.com (Randell Jesup), gibbs@scsiguy.com (Justin T. Gibbs), dillon@earth.backplane.com (Matt Dillon), phk@critter.freebsd.dk (Poul-Henning Kamp), bde@zeta.org.au (Bruce Evans), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG In-Reply-To: <3A087257.DBA40791@elischer.org> from "Julian Elischer" at Nov 07, 2000 01:21:27 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think both Matt's changes and what Poul-Henning can be useful. > > (Actually, it sounds like Matt's are required, and Poul-Henning's might be > > nice if and when someone does them). > > I think that they are talking with cross purposes.. > > Matt is right that nothing that magically comes up with a few > hundred KB of ram can be guaranteed to stop a deadlock, because > after the few hundred KB have been used up, If the big memory > hog keeps eating memory, you are right back where you started, > and you no longer have a few hundred KB up your sleeve. Djikstra's Bankers Algorithm solves this by stalling the big memory hog, if it can't have pages stolen from it (i.e. have its working set size reduced). No CPU cycles granted to the hog equals no new allocations to the hog. I think that the problem being examined is the one that Poul and Matt and Alfred discussed a little while ago, where you have a hog, and its pages are marked as anonymous, yet are dirty. This is really an evil thing to do, since the pages are not permitted to be swapped, nor are they permitted to be cleaned. I think the right thing to do would be to treat the flag as a hint, not a granted right, and start swapping the pages anyway. A more ideal soloution would not let you get into trouble in the first place, by refusing to dirty buffers faster than they can be written -- in other words, if the system is overloaded, it slows down: degrading gracefully. > On the other hand, PHK is correct in that it would be a useful > facility to have and that it might buy some breathing space. > To be ueful however I think it would need to be combined with > some other measures to ensure that we don't get straight back > into debt. For example triggering that queue might change the > strategies in the kernel so that the biggest memory users are > forced to start losing pages. (e.g. it's swapped out) or some > similar work.. This will be, without a doubt, required, in order to ensure an artificial scarcity isn't created. You could consider this the case where you have per CPU resource pools, or you have memory tied up in other places, which could reasonably be recovered. NT and Windows 95/98/2000 both have the capability for the VM system to demand that resources be returned to it, under low memory conditions. This may not help, unless there is a reserve which is kept seperately for I/O buffers vs. other buffers, so the unified VM and buffer cache work against easily resolving this (this may be why Sun punted in Solaris 2.8, and deunified their cache again). As to another comment in this thread, SIGDANGER was intended to make processes free up resources, not the system, so I don't think the AIX approach will work here. Arguably, if one is going to do what Yahoo has been doing in order to workaround other problems, the memory that gets allocated to this purpose should probably be (1) wired down, and (2) size restricted to say 75% of available memory, or some other hard limit. Effectively, memory used in such a way as to cause this problem should probably not be overcommitted. There's also the historical problem with page reclaimation, after the disassociation of an in core inode with the vnode off which clean buffers are hung. This is, inded, wasted memory, and those buffers should probably be released sooner, when the inode/vnode relationship is severed, rather than later, when the reclaimer gets around to it. I'd actually be really interested in the statistics with regard to "reclaimable clean vs. dirty memory" for a system once it has hit "extreme low memory conditions" leading to deadlock. I think that you couldn't say that "low memory conditions always result from X, and never from Y", and that different usage patterns would mean different root causes -- and thus different "optimal recovery strategies". Anyway, real statistics gathered at or near the failure point for these systems would be truly useful; if all the memory is fragmented, then kicking subsystems to make them release what they can won't help (I personally doubt this will be the case). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 17:12:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id BD4ED37B4C5 for ; Tue, 7 Nov 2000 17:12:35 -0800 (PST) Received: (qmail 93204 invoked from network); 8 Nov 2000 01:11:03 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2000 01:11:03 -0000 Message-ID: <3A08A882.AA428418@telehouse.ch> Date: Wed, 08 Nov 2000 02:12:34 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Paul Saab , Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> <3A0892BB.4F399708@telehouse.ch> <20001107184940.X37870@jade.chc-chimes.com> <3A0896EC.A2CA3106@telehouse.ch> <20001107192754.Y37870@jade.chc-chimes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Wed, Nov 08, 2000 at 12:57:32AM +0100, Andre Oppermann wrote: > > > If you had read my previous email further, instead of just stopping > > after the first sentence that apparently offended you, you would have > > seen that I come to the same conclusion with the twist that the change > > of behaviour should happen on a per sub-system basis, not on a global > > kernel-KVM basis. > > I think that a subsystem variable could have value, but there are portions > of the kernel that an attack on one subsystem has a large effect on others. Yes, that's why each subsystem should look after it's own business. Let's have an example: There is a DoS attack being launched with thousands of TCP connections to some port. Now let's assume this would use up all available KVM resources. The thousand-and-first TCP connection cannot be handled anymore because there is no free KVM any more. Now the INET Networking subsystem has two options: 1) make some resources available, eg. drop all fin_wait connections, 2) refuse to accept this connection. OK, of course the VM I/O is seeing the same problem, no more memory available. So it has to look also after it's own business and clean up, flush caches etc. So you are absolutely right in saying that an attack or heavy usage on one subsystem has an effect on others. But I say in this case don't tell the VM to make memory free for the INET subsystem. Because if you do that you get a situation where one subsystem can monopolize the available system resources more or less which makes an possible DoS attach or just an heavy usage case much more effective; the whole system breaks down, even the not directly related parts of it. We don't allow this in userland, why should we do in the kernel? The right solution is to promote the information of shortage back to the originator but not let one part of the system take it all. In a subsystem local solution the resource distribution would look like this (in the KVM): Normal operation; INET 20%, VMIO 20%, 60% free Some app processing logs; INET 20%, VMIO 40%, 40% free TCP attack begins; INET 60%, VMIO 40%, 0% free Now each subsystem has it got it's max as available right now and have to live with it. easy. INET has chew on the TCP connections but the application processing logs is still alive and proceeding. OK, the VMIO will not get any more memory and has to complete the outstanding I/O before doing new but it's not dead in the water. Lets have a look what would happen if set now the proposed global emergency flag in the VM: Global emergency flag; INET 90%, VMIO 10%, 0% free Ugh, the application doing log processing comes to a grinding halt and the INET sucks every available byte in to handle the attack. I would say that's a really sucessful attack! The idea of subsystem local shortage handling is to maintain state. You can keep what you have but you don't get any more if we are in a shortage case. Of course the systems performace will be degraded but it will not drop down on the floor. Important is to make the subsystems dead-lock free if they can't get any more memory and teach them how to free stuff for themselfes, not the others, to continue operation. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 17:13:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 46B2D37B479 for ; Tue, 7 Nov 2000 17:13:21 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA19948; Tue, 7 Nov 2000 18:11:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAALVaWqI; Tue Nov 7 18:06:29 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA01195; Tue, 7 Nov 2000 18:08:14 -0700 (MST) From: Terry Lambert Message-Id: <200011080108.SAA01195@usr08.primenet.com> Subject: Re: softdep panic due to blocked malloc (with traceback) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 8 Nov 2000 01:08:14 +0000 (GMT) Cc: drosih@rpi.edu (Garance A Drosihn), dillon@earth.backplane.com (Matt Dillon), bde@zeta.org.au (Bruce Evans), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG In-Reply-To: <27538.973633262@critter> from "Poul-Henning Kamp" at Nov 07, 2000 10:41:02 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>Could we please have an eventhandler chain which gets called when > >>we are short of KVM ? There are code which can free KVM with no > >>significant loss of anything but performance, if only we bother to > >>tell it to do so. > > > >Do you mean something like the SIGDANGER signal, which is available > >under aix? (I'm just wondering) > > That too might be a very good idea. It's a user space signal, which can be caught to prevent termination of "precious" processes. It is also (infrequently) used for self checkpoint/restart, so it's caught to shutdown, rather than terminate processes. I haven't seen an occurrance of one in nature (well, AIX) in at least 5 years. A kernel event handler chain is probably a good idea (see previous notes on NT and Windows). The way it's usually handled is by not giving anyone who pools resources any allocations, unless they register a "give back as much as you can" handlers. It's amusing to note that VFAT only ever gave back exactly one page (some pigs are more equal than others). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 18: 0:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3B47A37B479 for ; Tue, 7 Nov 2000 18:00:44 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3O00I7ZO958Q@falla.videotron.net> for arch@FreeBSD.ORG; Tue, 7 Nov 2000 21:00:41 -0500 (EST) Date: Tue, 07 Nov 2000 21:05:33 -0500 (EST) From: Bosko Milekic Subject: Re: Green/Yellow/Red state for the VM system. In-reply-to: <3A08A882.AA428418@telehouse.ch> X-Sender: bmilekic@jehovah.technokratis.com To: Andre Oppermann Cc: arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Nov 2000, Andre Oppermann wrote: > Let's have an example: There is a DoS attack being launched with > thousands of TCP connections to some port. Now let's assume this > would use up all available KVM resources. The thousand-and-first > TCP connection cannot be handled anymore because there is no free > KVM any more. Now the INET Networking subsystem has two options: > 1) make some resources available, eg. drop all fin_wait connections, > 2) refuse to accept this connection. You forget about something. (2) has serious implications which are not favorable. The system is not only going to refuse to accept the connection, but it's going to get so wedged that it's going to start dropping packets. The idea with the "yellow" flag would be to stop accepting new connections, and rather just deal with the presently established connections. This is way better than just dropping random packets. Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 18:13: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id B0DEF37B479; Tue, 7 Nov 2000 18:12:54 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3O00I66OTGX6@falla.videotron.net>; Tue, 7 Nov 2000 21:12:53 -0500 (EST) Date: Tue, 07 Nov 2000 21:17:45 -0500 (EST) From: Bosko Milekic Subject: Re: Green/Yellow/Red state for the VM system. In-reply-to: <28041.973635706@critter> X-Sender: bmilekic@jehovah.technokratis.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Nov 2000, Poul-Henning Kamp wrote: > The easiest way to deal with overload and DoS attacks is to recognize > them as such, go into defensive mode and weather it. This is a reasonable philosophy. > If we implement a generic facility for this, we will have a lot less > worries about future DoS attacks, because our generic mechanism will > deal with a lot of them on its own. > > The facility I hinted at in an earlier email is this: > > The VM system maintains an enum variables: > > enum {GREEN, YELLOW, RED} kvm_light; > > When kvm_light changes value, a kernel event-handler list is activiated. The problem with this "general" approach is that it would be wrong to apply it on a global scale, in all cases. For instance, subsystems which allocate wired-down pages only to never free them back (but keep them on their cache for performance reasons) can do very little for other subsystems waiting for a page to become available. (I'll bet you're thinking "there goes Bosko with his mbuf cr*p again." :-)) But, really though, having network components start freeing memory, often (but not always) in the form of mbufs or mbuf clusters, isn't going to help out some subsystem X waiting for a page to become available. I propose that the general "flag" system allows the possibility for subsystems to maintain their own private 'flags' to which other subsystems can optionally react to, but not have one single "kvm_state/light" affecting everything, especially when it comes to INET-related things. I'm up for working on this after we're done with more of the SMPng work, as I would not like to damage the general "wave" of things. [...] I suggest that when this does go into full-effect that we look at different "lights" or "states" and partly associate them with uses of certain common functions, such as "malloc()." In other words, malloc() users will have to react differently once they notice a "flag" go up. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. Overall, I like this idea as it has potential to make the system act "smarter" in tight situations, but I would advise everybody to proceed with a more "specifics/finer-grain" approach (as opposed to the _general_ "vm_state" flag approach). Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 7 22:29:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 36A6137B479 for ; Tue, 7 Nov 2000 22:29:31 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA86T6D29405; Wed, 8 Nov 2000 07:29:06 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann Cc: Paul Saab , arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. In-Reply-To: Your message of "Wed, 08 Nov 2000 00:39:39 +0100." <3A0892BB.4F399708@telehouse.ch> Date: Wed, 08 Nov 2000 07:29:06 +0100 Message-ID: <29403.973664946@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A0892BB.4F399708@telehouse.ch>, Andre Oppermann writes: >> > I don't think this is necessary at all after Matt's and Paul's code >> > being commited. Why? Because the box would not wedge solid or panic >> > anymore. >> >> I wouldn't make such a bold statement.. We find all sorts of interesting >> bugs on a daily basis and I would bet money we'll find another way to >> lockup the system. > >OK, but would the right solution be to simply make more memory >available? I doubt it. A bug is a bug and needs to be fixed not >to be masked. Eventually it would fail just in a different place. You overlook the fact that my change will be an automatic remedy for several classes of DoS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 0:46:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 9306437B479 for ; Wed, 8 Nov 2000 00:46:25 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA872ZD29942; Wed, 8 Nov 2000 08:02:35 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Tue, 07 Nov 2000 15:28:37 PST." <20001107152836.I5112@fw.wintelcom.net> Date: Wed, 08 Nov 2000 08:02:35 +0100 Message-ID: <29940.973666955@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001107152836.I5112@fw.wintelcom.net>, Alfred Perlstein writes: >> Could we please have an eventhandler chain which gets called when >> we are short of KVM ? There are code which can free KVM with no >> significant loss of anything but performance, if only we bother to >> tell it to do so. > >Wait a second, didn't you argue against doing this when I proposed it >nearly a year ago? I argued against having only two colors and in favour of three (or more) colors. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 0:53:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6A06E37B479 for ; Wed, 8 Nov 2000 00:53:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA88pVp00480; Wed, 8 Nov 2000 00:51:31 -0800 (PST) Date: Wed, 8 Nov 2000 00:51:31 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <20001108005130.R5112@fw.wintelcom.net> References: <20001107152836.I5112@fw.wintelcom.net> <29940.973666955@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <29940.973666955@critter>; from phk@critter.freebsd.dk on Wed, Nov 08, 2000 at 08:02:35AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [001108 00:46] wrote: > In message <20001107152836.I5112@fw.wintelcom.net>, Alfred Perlstein writes: > > >> Could we please have an eventhandler chain which gets called when > >> we are short of KVM ? There are code which can free KVM with no > >> significant loss of anything but performance, if only we bother to > >> tell it to do so. > > > >Wait a second, didn't you argue against doing this when I proposed it > >nearly a year ago? > > I argued against having only two colors and in favour of three (or > more) colors. I'm sorry, I didn't mean to be short with you, what I remeber is you being very against callbacks into subsystems to free the RAM, basically only doing the "free 2, allocate 1" thing when you normally entered a subsystem, not during a callback which has a lot of lock ordering problems (your point if I remeber correctly). Callbacks can be a bad idea because of lock ordering as well as possible resource allocation recursion. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 0:55:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 371BD37B4C5 for ; Wed, 8 Nov 2000 00:55:36 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA88tGD30681; Wed, 8 Nov 2000 09:55:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Matt Dillon , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) In-Reply-To: Your message of "Wed, 08 Nov 2000 00:51:31 PST." <20001108005130.R5112@fw.wintelcom.net> Date: Wed, 08 Nov 2000 09:55:16 +0100 Message-ID: <30679.973673716@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001108005130.R5112@fw.wintelcom.net>, Alfred Perlstein writes: >* Poul-Henning Kamp [001108 00:46] wrote: >> In message <20001107152836.I5112@fw.wintelcom.net>, Alfred Perlstein writes: >> >> >> Could we please have an eventhandler chain which gets called when >> >> we are short of KVM ? There are code which can free KVM with no >> >> significant loss of anything but performance, if only we bother to >> >> tell it to do so. >> > >> >Wait a second, didn't you argue against doing this when I proposed it >> >nearly a year ago? >> >> I argued against having only two colors and in favour of three (or >> more) colors. > >I'm sorry, I didn't mean to be short with you, what I remeber is >you being very against callbacks into subsystems to free the RAM, >basically only doing the "free 2, allocate 1" thing when you normally >entered a subsystem, not during a callback which has a lot of lock >ordering problems (your point if I remeber correctly). > >Callbacks can be a bad idea because of lock ordering as well as >possible resource allocation recursion. Well, the callbacks are needed to tell the subsystem that things have changed, but otherwise you're right, the majority of the work should be done "in the normal course of events" with a footnote that going into RED means "anything goes". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 3:11:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 27A6C37B479 for ; Wed, 8 Nov 2000 03:11:17 -0800 (PST) Received: from newsguy.com (p14-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.79]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id UAA12482; Wed, 8 Nov 2000 20:11:13 +0900 (JST) Message-ID: <3A09346F.7543C1DD@newsguy.com> Date: Wed, 08 Nov 2000 20:09:35 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <200011080108.SAA01195@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > I haven't seen an occurrance of one in nature (well, AIX) in at > least 5 years. I did... :-( And wished the damned application knew about the signal and stopped hogging memory. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@world.wide.bsdconspiracy.net He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 10:17:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 8DFBC37B479 for ; Wed, 8 Nov 2000 10:17:43 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id LAA04339; Wed, 8 Nov 2000 11:18:13 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAA8Mayui; Wed Nov 8 11:17:55 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA21138; Wed, 8 Nov 2000 11:17:14 -0700 (MST) From: Terry Lambert Message-Id: <200011081817.LAA21138@usr08.primenet.com> Subject: Re: softdep panic due to blocked malloc (with traceback) To: dcs@newsguy.com (Daniel C. Sobral) Date: Wed, 8 Nov 2000 18:17:14 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <3A09346F.7543C1DD@newsguy.com> from "Daniel C. Sobral" at Nov 08, 2000 08:09:35 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I haven't seen an occurrance of one in nature (well, AIX) in at > > least 5 years. > > I did... :-( > And wished the damned application knew about the signal and stopped > hogging memory. ??? It's my experience that if you don't trap the thing, you terminate. Did your application ignore the thing when you didn't want it to, or did it terminate, when you didn't want want it to? If the former, I'd have to say that that was a very badly behaved program indeed, if it trapped and ignored the signal, since it's probably trapping and ignoring other signals (all of them?) that it's too stupid to handle properly. If the latter, well, that's a consequence of running within a memory overcommit architecture, without enough swap, and no emergency measures, like the ones which are being put forward by Poul and DES in this thread. I think that, under no circumstances, should it be permited to wedge a system, no matter how loaded it gets. Wedging individual processes is acceptable, IMO, until such time as necessary resources become available. This may include such things as preallocation of trap/fault handling resources, and blocking programs in the trap/fault handler, for an indefinite period of time. For example, an overcommit of a data page, which gets a copy-on-write fault, when there are no pages available to copy to. If it didn't have extra cost to sleep these, then sleeping them isn't a big deal. I think a partial fix has to be the idea that some code ought to be statically linked, have the sticky bit set, and making the kernel honor the traditional sticky bit semantics. I put "init", "inetd", "/bin/login", "/bin/sh", "/bin/kill", and similar programs needed to recover a wedged system into this camp. The whole idea of "sacrosanct" processes reall ignores the idea that one of those processes could be a victim of a DOS attack. I really oppose something like "SIGDANGER" because of this. I think user space processes can be adequately managed through administrative limits on resource consumption. I think the real problem will be kernel space resource utilization, where administrative limits aren't enforced, either out of fear of deadlock, or for other less defensible reasons. The biggest things I would put in this category are things that run in kernel threads, and so need access to scheduler quantum, in order to run. It seems to me that one approach would be to run these to completion in the resource allocation handlers, rather than in the background (the same way the Dynix allocator handles freeing resources to the system, and doing page coelesces). For things that absolutely have to run in the background, and so are a kernel thread or a kernel process or whatever you want to call it, I think that the answer might be to change the scheduler to support multiple scheduling classes, and then put these things into a fixed scheduling class. This would guarantee that they were alotted quanta, up to a certain fixed percentage of available quanta, if they needed it. It would let them run things like I/O to completetion. UnixWare has successfully used a similar approach, since UnixWare 2.0 (1994), with moderately good results. I also think that working set quotas for any resource are probably a good idea, since it puts the ofeender into its own competition domain, where it can only thrash itself, and no one else notices it. A good example of this would be "TCP/IP connection requests from w.x.y.z", where you limit the allowed number of outstanding requests based on the requester, rather than trying to do it globally. This still leaves you open to attacks from multiple source addresses simultaneously, but that needs to be handled anyway, and probably can't be handled at a global resource utilization level, and still permit legitimate traffic. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 14:57:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id 4AA6537B479 for ; Wed, 8 Nov 2000 14:57:15 -0800 (PST) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 49DCE25360; Wed, 8 Nov 2000 17:57:09 -0500 (EST) Received: by osaka.louisville.edu (Postfix, from userid 15) id 6F3F01861D; Wed, 8 Nov 2000 17:57:04 -0500 (EST) Date: Wed, 8 Nov 2000 17:57:04 -0500 From: Keith Stevenson To: Terry Lambert Cc: "Daniel C. Sobral" , arch@FreeBSD.ORG Subject: AIX SIGDANGER (was Re: softdep panic due to blocked malloc) Message-ID: <20001108175704.B1405@osaka.louisville.edu> References: <3A09346F.7543C1DD@newsguy.com> <200011081817.LAA21138@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011081817.LAA21138@usr08.primenet.com>; from tlambert@primenet.com on Wed, Nov 08, 2000 at 06:17:14PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a bit offtopic, but I couldn't help myself. (I'm an AIX admin) Quoting IBM's July 2000 system documentation CDROM: The system monitors the number of free paging space blocks and detects when a paging-space shortage exists. When the number of free paging-space blocks falls below a threshold known as the paging-space warning level, the system informs all processes (except kprocs) of this condition by sending the SIGDANGER signal. If the shortage continues and falls below a second threshold known as the paging-space kill level, the system sends the SIGKILL signal to processes that are the major users of paging space and that do not have a signal handler for the SIGDANGER signal (the default action for the SIGDANGER signal is to ignore the signal). The system continues sending SIGKILL signals until the number of free paging-space blocks is above the paging-space kill level. So, SIGDANGER doesn't buy you much unless your applications have a handler for it. (In my experience, most don't.) I was not very happy when I hit a low memory situation and AIX started committing random acts of violence against my process table. The system ended up being so hosed, I had to reboot to maintenance mode and repair a bunch of datafiles. (One of our production applications doesn't SIGKILL gracefully.) I think that SIGDANGER would make a lot more sense if its default action was the same as SIGTERM. SIGKILL'ing everything in sight isn't a lot cleaner (IMO) than letting the system crash. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville keith.stevenson@louisville.edu GPG key fingerprint = 332D 97F0 6321 F00F 8EE7 2D44 00D8 F384 75BB 89AE On Wed, Nov 08, 2000 at 06:17:14PM +0000, Terry Lambert wrote: > > > I haven't seen an occurrance of one in nature (well, AIX) in at > > > least 5 years. > > > > I did... :-( > > And wished the damned application knew about the signal and stopped > > hogging memory. > > ??? > > It's my experience that if you don't trap the thing, you > terminate. Did your application ignore the thing when you > didn't want it to, or did it terminate, when you didn't want > want it to? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 17:55:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id AAD2037B479 for ; Wed, 8 Nov 2000 17:55:33 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA91tTg17287 for ; Wed, 8 Nov 2000 18:55:30 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA35024 for ; Wed, 8 Nov 2000 18:55:29 -0700 (MST) Message-Id: <200011090155.SAA35024@harmony.village.org> To: arch@freebsd.org Subject: The shared /bin and /sbin bikeshed Date: Wed, 08 Nov 2000 18:55:29 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a patch that makes /bin and /sbin optionally non-static. For small systems that have / and /usr on the same file system, you can save about 5M-6M of disk space by making /bin and /sbin shared. Since this is undesirable for systems that have / and /usr on different file systems, I thought I'd make an option. What should I call the option? I'm thinking SLASHED_SHARED, but that's a horrible name. I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too long Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 18:11:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.hiwaay.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id B56CC37B65F for ; Wed, 8 Nov 2000 18:11:43 -0800 (PST) Received: from bonsai.knology.net (user-24-214-88-8.knology.net [24.214.88.8]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id eA92BY728244; Wed, 8 Nov 2000 20:11:34 -0600 (CST) Received: (from steve@localhost) by bonsai.knology.net (8.11.0/8.9.3) id eA92BTa62485; Wed, 8 Nov 2000 20:11:29 -0600 (CST) (envelope-from steve) Date: Wed, 8 Nov 2000 20:11:29 -0600 From: Steve Price To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001108201129.C62344@bonsai.knology.net> References: <200011090155.SAA35024@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011090155.SAA35024@harmony.village.org>; from imp@village.org on Wed, Nov 08, 2000 at 06:55:29PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 08, 2000 at 06:55:29PM -0700, Warner Losh wrote: # # I have a patch that makes /bin and /sbin optionally non-static. For # small systems that have / and /usr on the same file system, you can # save about 5M-6M of disk space by making /bin and /sbin shared. This might be a bit off-topic but I wonder how much this would help the PicoBSD distribution if it isn't done this way already? -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 18:19:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5FD8A37B4C5 for ; Wed, 8 Nov 2000 18:19:08 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA92J7g17398; Wed, 8 Nov 2000 19:19:07 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA35291; Wed, 8 Nov 2000 19:19:06 -0700 (MST) Message-Id: <200011090219.TAA35291@harmony.village.org> To: Steve Price Subject: Re: The shared /bin and /sbin bikeshed Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 08 Nov 2000 20:11:29 CST." <20001108201129.C62344@bonsai.knology.net> References: <20001108201129.C62344@bonsai.knology.net> <200011090155.SAA35024@harmony.village.org> Date: Wed, 08 Nov 2000 19:19:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001108201129.C62344@bonsai.knology.net> Steve Price writes: : On Wed, Nov 08, 2000 at 06:55:29PM -0700, Warner Losh wrote: : # : # I have a patch that makes /bin and /sbin optionally non-static. For : # small systems that have / and /usr on the same file system, you can : # save about 5M-6M of disk space by making /bin and /sbin shared. : : This might be a bit off-topic but I wonder how much this would : help the PicoBSD distribution if it isn't done this way already? None. PicoBSD uses cruncgen to compile all its binaries into one super binary. There are no shared libraries. I'm not using the PicoBSD model for two reasons. One, we need the flexibility to update one file on the part in the field. This isn't easy to do with the compressed image of the file system in place. Second, we'd rather spend the RAM on application space rather than MFS space. This basically makes it easier to build my "small FreeBSD image" using some custom scripts (I posted them once and there wasn't much interest). It works well for creating subsets of the entire system, but it is an expert tool right now requiring some care and feeding as the system drift away from the initial version (eg more changed its name to less, so make install from src/usr.bin/more no longer worked). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 18:48:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AC3C337B4C5 for ; Wed, 8 Nov 2000 18:48:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA92mdN05702; Wed, 8 Nov 2000 18:48:39 -0800 (PST) Date: Wed, 8 Nov 2000 18:48:39 -0800 From: Alfred Perlstein To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001108184838.L5112@fw.wintelcom.net> References: <200011090155.SAA35024@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011090155.SAA35024@harmony.village.org>; from imp@village.org on Wed, Nov 08, 2000 at 06:55:29PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [001108 17:55] wrote: > > I have a patch that makes /bin and /sbin optionally non-static. For > small systems that have / and /usr on the same file system, you can > save about 5M-6M of disk space by making /bin and /sbin shared. > > Since this is undesirable for systems that have / and /usr on > different file systems, I thought I'd make an option. > > What should I call the option? > > I'm thinking SLASHED_SHARED, but that's a horrible name. > > I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too > long I was going to say "DYNAMIC_BINARIES" but that sounds too much like a staurday morning cartoon show... how about DYNAMIC_BIN_SBIN? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 18:49: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 84B8237B4C5 for ; Wed, 8 Nov 2000 18:48:59 -0800 (PST) Received: (qmail 9271 invoked by uid 3130); 9 Nov 2000 02:48:57 -0000 Message-ID: <20001108214857.A9165@electricjellyfish.net> Date: Wed, 8 Nov 2000 21:48:57 -0500 From: Garrett Rooney To: Warner Losh , arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed References: <200011090155.SAA35024@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <200011090155.SAA35024@harmony.village.org>; from Warner Losh on Wed, Nov 08, 2000 at 06:55:29PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 08, 2000 at 06:55:29PM -0700, Warner Losh wrote: > > I have a patch that makes /bin and /sbin optionally non-static. For > small systems that have / and /usr on the same file system, you can > save about 5M-6M of disk space by making /bin and /sbin shared. > > Since this is undesirable for systems that have / and /usr on > different file systems, I thought I'd make an option. > > What should I call the option? > > I'm thinking SLASHED_SHARED, but that's a horrible name. > > I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too > long BIN_SBIN_SHARED ? simple, to the point, and short. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 18:49:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3771937B479 for ; Wed, 8 Nov 2000 18:49:38 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA92nbg17475 for ; Wed, 8 Nov 2000 19:49:37 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA35455 for ; Wed, 8 Nov 2000 19:49:36 -0700 (MST) Message-Id: <200011090249.TAA35455@harmony.village.org> To: arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Wed, 08 Nov 2000 20:04:31 CST." <20001108200431.A62344@bonsai.knology.net> References: <20001108200431.A62344@bonsai.knology.net> <200011090155.SAA35024@harmony.village.org> Date: Wed, 08 Nov 2000 19:49:36 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : I have a patch that makes /bin and /sbin optionally non-static. For : small systems that have / and /usr on the same file system, you can : save about 5M-6M of disk space by making /bin and /sbin shared. It looks like I understated the savings. It saves 6.5M for our cut down tree (which tries to grab as few of the /bin and /sbin binaries as it can). For the full tree it saves 12-13M (2.1M vs 14.4M). My cut down minimal system went from 14.7M to 8.2M. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 19: 0:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id A136237B681 for ; Wed, 8 Nov 2000 19:00:00 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA935W900472; Wed, 8 Nov 2000 19:05:32 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011090305.eA935W900472@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Wed, 08 Nov 2000 18:48:39 PST." <20001108184838.L5112@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Nov 2000 19:05:32 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What should I call the option? > > > > I'm thinking SLASHED_SHARED, but that's a horrible name. > > > > I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too > > long NO_STATIC_BINARIES NO_STATIC_LIBRARIES (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force people to change) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 19: 2:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 8AB8337B479 for ; Wed, 8 Nov 2000 19:02:12 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id TAA32052; Wed, 8 Nov 2000 19:02:10 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda32050; Wed Nov 8 19:02:02 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eA9322W13678; Wed, 8 Nov 2000 19:02:02 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdM13672; Wed Nov 8 19:01:26 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eA931Pv26563; Wed, 8 Nov 2000 19:01:25 -0800 (PST) Message-Id: <200011090301.eA931Pv26563@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdr26532; Wed Nov 8 19:00:58 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Wed, 08 Nov 2000 19:49:36 MST." <200011090249.TAA35455@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Nov 2000 19:00:58 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011090249.TAA35455@harmony.village.org>, Warner Losh writes: > : I have a patch that makes /bin and /sbin optionally non-static. For > : small systems that have / and /usr on the same file system, you can > : save about 5M-6M of disk space by making /bin and /sbin shared. > > It looks like I understated the savings. It saves 6.5M for our cut > down tree (which tries to grab as few of the /bin and /sbin binaries > as it can). For the full tree it saves 12-13M (2.1M vs 14.4M). My > cut down minimal system went from 14.7M to 8.2M. I think it's a no brainer then. Another idea: Building static and dynamic binaries and storing them in separate directories within /usr/obj would allow for one buildworld to be used to installworld on larger (static) and smaller (dynamic) systems without running buildworld twice. BTW, it should be painted green. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 19:12: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2FBB237B479 for ; Wed, 8 Nov 2000 19:12:03 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA93C1g17562; Wed, 8 Nov 2000 20:12:01 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA35599; Wed, 8 Nov 2000 20:12:00 -0700 (MST) Message-Id: <200011090312.UAA35599@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: The shared /bin and /sbin bikeshed Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 08 Nov 2000 19:00:58 PST." <200011090301.eA931Pv26563@cwsys.cwsent.com> References: <200011090301.eA931Pv26563@cwsys.cwsent.com> Date: Wed, 08 Nov 2000 20:12:00 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011090301.eA931Pv26563@cwsys.cwsent.com> Cy Schubert - ITSD Open Systems Group writes: : Another idea: Building static and dynamic binaries and storing them in : separate directories within /usr/obj would allow for one buildworld to : be used to installworld on larger (static) and smaller (dynamic) : systems without running buildworld twice. : : BTW, it should be painted green. I'll put the bike shed in place, and let others paint it green :-) I'm very happy at the savings. On my CF part, I've saved enough to squeeze onto a 8M part in a pinch (obviously with no application, but with a few of the frequently requested binaries like csh). Not bad for 15 minutes worth of hacking and a lot of waiting for buildworld to finish :-) I'm leaning toward DYNAMIC_ROOT_BINS right now. I like Mike's idea to have a NO_STATIC_LIBRARIES as well, which would make installing onto the flash easier (since I install them now and then later blow them away). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 20:10:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E6C4337B479 for ; Wed, 8 Nov 2000 20:10:12 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id PAA16633; Thu, 9 Nov 2000 15:09:42 +1100 Date: Thu, 9 Nov 2000 15:10:07 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Steve Price , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011090219.TAA35291@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Nov 2000, Warner Losh wrote: > In message <20001108201129.C62344@bonsai.knology.net> Steve Price writes: > : On Wed, Nov 08, 2000 at 06:55:29PM -0700, Warner Losh wrote: > : # > : # I have a patch that makes /bin and /sbin optionally non-static. For > : # small systems that have / and /usr on the same file system, you can > : # save about 5M-6M of disk space by making /bin and /sbin shared. > : > : This might be a bit off-topic but I wonder how much this would > : help the PicoBSD distribution if it isn't done this way already? > > None. PicoBSD uses cruncgen to compile all its binaries into one > super binary. There are no shared libraries. I once used it (not Warner's version) to put a useful number of gzipped binaries on a 1.2MB floppy: --- total 5 drwxr-xr-x 2 bin bin 512 May 11 1996 bin/ drwxr-xr-x 2 root bin 1536 May 11 1996 dev/ drwxr-xr-x 2 root wheel 512 May 10 1996 etc/ drwxr-xr-x 2 bin bin 512 May 10 1996 lib/ drwxr-xr-x 2 bin bin 512 May 10 1996 sbin/ drwxrwxrwt 2 root wheel 512 May 11 1996 tmp/ drwxr-xr-x 6 bde wheel 512 May 10 1996 usr/ drwxr-xr-x 3 root wheel 512 May 11 1996 var/ ./bin: total 218 -r-xr-xr-x 2 bin bin 4208 Mar 27 1996 [* -r-xr-xr-x 1 bin bin 3288 Mar 27 1996 cat* -r-xr-xr-x 1 bin bin 2672 Feb 12 1996 chmod* -r-xr-xr-x 1 bin bin 5012 Mar 9 1996 cp* -r-xr-xr-x 1 bin bin 4333 Apr 6 1996 date* -r-xr-xr-x 1 bin bin 7194 Mar 27 1996 dd* -r-xr-sr-x 1 bin operator 4278 Feb 12 1996 df* -r-xr-xr-x 1 bin bin 1844 Feb 12 1996 domainname* -r-xr-xr-x 1 bin bin 1848 Feb 12 1996 echo* -r-xr-xr-x 2 bin bin 17744 Mar 27 1996 ed* -r-xr-xr-x 1 bin bin 5110 May 5 1996 expr* -r-xr-xr-x 1 bin bin 2028 Feb 12 1996 hostname* -r-xr-xr-x 1 bin bin 2434 Mar 27 1996 kill* -r-xr-xr-x 1 bin bin 2464 Feb 12 1996 ln* -r-xr-xr-x 1 bin bin 7230 Apr 5 1996 ls* -r-xr-xr-x 2 bin bin 2353 Feb 12 1996 md* -r-xr-xr-x 2 bin bin 2353 Feb 12 1996 mkdir* -r-xr-xr-x 1 bin bin 3663 Mar 2 1996 mv* -r-xr-xr-x 1 bin bin 34971 Feb 12 1996 pax* -r-xr-xr-x 1 bin bin 1881 Feb 12 1996 pwd* -r-sr-xr-x 1 root bin 7805 Mar 27 1996 rcp* -r-xr-xr-x 2 bin bin 1879 Feb 12 1996 rd* -r-xr-xr-x 2 bin bin 17744 Mar 27 1996 red* -r-xr-xr-x 1 bin bin 4820 Mar 8 1996 rm* -r-xr-xr-x 1 bin bin 3998 Mar 27 1996 rmail* -r-xr-xr-x 2 bin bin 1879 Feb 12 1996 rmdir* -r-xr-xr-x 1 bin bin 44971 May 9 1996 sh* -r-xr-xr-x 1 bin bin 1857 Feb 12 1996 sleep* -r-xr-xr-x 1 bin bin 7933 Feb 12 1996 stty* -r-xr-xr-x 1 bin bin 1623 Feb 12 1996 sync* -r-xr-xr-x 2 bin bin 4208 Mar 27 1996 test* ./dev: total 30 -rw-r--r-- 1 root wheel 30379 May 4 1996 MAKEDEV ... ./etc: total 17 -rw-r--r-- 1 root wheel 7117 Jan 16 1996 disktab -rw-r--r-- 1 bin bin 25 May 11 1996 fstab -rw-r--r-- 1 root wheel 785 Mar 23 1996 localtime -rw-r--r-- 1 bde wheel 2301 Dec 7 1995 profile -rw-r--r-- 1 bde bin 5853 Feb 1 1996 termcap ./lib: total 566 lrwxrwxrwx 1 bin bin 11 May 10 1996 libc.so.2.2@ -> libc.so.3.0 -r--r--r-- 1 bin bin 388291 May 9 1996 libc.so.3.0 lrwxrwxrwx 1 bin bin 16 May 10 1996 libcrypt.so.2.0@ -> libscrypt.so.2.0 -r--r--r-- 1 bin bin 70195 Apr 20 1996 libedit.so.2.0 -r--r--r-- 1 bin bin 26376 Feb 5 1995 libgcc.so.261.0 -r--r--r-- 1 bin bin 8352 Apr 20 1996 libipx.so.2.0 -r--r--r-- 1 bin bin 17022 Apr 20 1996 libkvm.so.2.0 -r--r--r-- 1 bin bin 12489 Apr 20 1996 libscrypt.so.2.0 -r--r--r-- 1 bin bin 17059 Apr 20 1996 libscsi.so.2.0 -r--r--r-- 1 bin bin 16736 May 8 1996 libtermcap.so.2.1 -r--r--r-- 1 bin bin 8459 Apr 20 1996 libutil.so.2.1 ./sbin: total 176 -r-xr-xr-x 1 bin bin 9835 May 5 1996 disklabel* -r-xr-xr-x 1 bin bin 6244 Feb 12 1996 fdisk* -r-xr-xr-x 1 bin bin 27879 May 5 1996 fsck* -r-xr-xr-x 1 bin bin 6242 May 9 1996 ifconfig* -r-x------ 1 bin bin 7466 May 9 1996 init* -r-xr-xr-x 1 bin bin 61440 May 9 1996 ld.so* -r-xr-xr-x 1 bin bin 5019 Apr 21 1996 ldconfig* -r-xr-xr-x 1 bin bin 1908 Feb 12 1996 mknod* -r-xr-xr-x 1 bin bin 5994 Mar 15 1996 mount* -r-xr-xr-x 1 bin bin 15515 Feb 12 1996 newfs* -r-sr-xr-x 1 root bin 7482 May 5 1996 ping* -r-xr-xr-x 1 bin bin 2713 Feb 12 1996 reboot* -r-xr-xr-x 1 bin bin 7205 Apr 7 1996 scsi* -r-xr-xr-x 1 bin bin 2117 Feb 12 1996 swapon* -r-xr-xr-x 1 bin bin 4214 Feb 12 1996 umount* ./tmp: ./usr: total 2 drwxr-xr-x 3 bde wheel 512 May 10 1996 bde/ drwxr-xr-x 2 bin bin 512 May 10 1996 bin/ drwxr-xr-x 2 bin bin 512 May 10 1996 mdec/ drwxr-xr-x 2 bin bin 512 May 11 1996 sbin/ ./usr/bde: total 1 drwxr-xr-x 2 bde wheel 512 May 10 1996 bin/ ./usr/bde/bin: total 122 -rwxr-xr-x 1 bde wheel 2238 Jan 10 1995 hd* -rwxr-xr-x 1 bde wheel 21756 Feb 23 1995 less* -rwxr-xr-x 1 bde wheel 13807 Jan 10 1995 rz* -rwxr-xr-x 1 bde wheel 16937 Jan 10 1995 sz* -rwxr-xr-x 1 bde wheel 1946 Jan 10 1995 tach* -rwxr-xr-x 1 bde wheel 2673 Jan 10 1995 term* -rwxr-xr-x 1 bde wheel 51176 Jul 1 1995 vi* -rwxr-xr-x 1 bde wheel 6434 Jan 10 1995 zap* ./usr/bin: total 11 -r-xr-xr-x 1 bin bin 3447 Feb 12 1996 cmp* -r-xr-xr-x 1 bin bin 2772 Feb 12 1996 du* -r-xr-xr-x 1 bin bin 4217 Feb 22 1996 mt* ./usr/mdec: total 8 -r--r--r-- 1 bin bin 512 Mar 1 1996 boot1 -r--r--r-- 1 bin bin 6912 Apr 28 1996 boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 bootfd@ -> boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 bootod@ -> boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 bootsd@ -> boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 bootvn@ -> boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 bootwd@ -> boot2 lrwxrwxrwx 1 bin bin 5 May 10 1996 fdboot@ -> boot1 lrwxrwxrwx 1 bin bin 5 May 10 1996 odboot@ -> boot1 lrwxrwxrwx 1 bin bin 5 May 10 1996 sdboot@ -> boot1 lrwxrwxrwx 1 bin bin 5 May 10 1996 vnboot@ -> boot1 lrwxrwxrwx 1 bin bin 5 May 10 1996 wdboot@ -> boot1 ./usr/sbin: total 13 -r-xr-xr-x 1 bin bin 6133 Feb 12 1996 bad144* -r-xr-xr-x 2 bin bin 3119 Feb 12 1996 chgrp* -r-xr-xr-x 2 bin bin 3119 Feb 12 1996 chown* ./var: total 1 drwxrwxrwt 2 root wheel 512 May 11 1996 tmp/ ./var/tmp: --- Linux was less bloated and could fit a much larger set of useful binaries. Everything is more bloated now, and I gave up attempting to fit things on floppies. > I'm not using the PicoBSD model for two reasons. One, we need the > flexibility to update one file on the part in the field. This isn't > easy to do with the compressed image of the file system in place. I avoided crunchgen for the same reason. gzipped binaries weren't very convenient either. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 8 20:26:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B860037B479 for ; Wed, 8 Nov 2000 20:26:44 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA94Qgg17840; Wed, 8 Nov 2000 21:26:43 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA36052; Wed, 8 Nov 2000 21:26:42 -0700 (MST) Message-Id: <200011090426.VAA36052@harmony.village.org> To: Bruce Evans Subject: Re: The shared /bin and /sbin bikeshed Cc: Steve Price , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Nov 2000 15:10:07 +1100." References: Date: Wed, 08 Nov 2000 21:26:42 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bruce Evans writes: : ./etc: : -rw-r--r-- 1 bde bin 5853 Feb 1 1996 termcap My termcap is only 1906 bytes long. Has network, dumb, unknown, ansi, vt100, xterm, and cons25 in it. I tried to get it down to 1536, but didn't want to give up the arrow keys :-) : Linux was less bloated and could fit a much larger set of useful binaries. : Everything is more bloated now, and I gave up attempting to fit things on : floppies. Yes. With libc running at 500k now, it is hard to get a useful set of binaries onto even a 1.44M floppy. My "minimal" set is running about 8M these days. Great for Timing Soltuion's embedded products with their 32M flash parts, bad for floppies. The basic floppy hasn't followed Moore's law, and the new super floppies are not well supported by various BIOSes. I also hope, and this may be wishful thinking on my part, to put together an X terminal in 16M for my iopener. Warner P.S. archive bloat: Note, I didn't wrap these at 80 columns to save about 50-80 bytes. network|dumb|unknown:am:co#80:do=^J: ansi:co#80:li#24:cl=50\E[;H\E[2J:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:ce=\E[K:ho=\E[H:pt: vt100:do=2\E[B:co#80:li#24:cl=50\E[H\E[J:sf=2*\ED:le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:if=/usr/share/tabset/vt100:nw=2\EE:ho=\E[H:as=2\E(0:ae=2\E(B:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:rs=\E>\E[?1;3;4;5l\E[?7;8h:ks=\E[?1h\E=:ke=\E[?1l\E>:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:pt:sr=2*\EM:vt#3:xn:sc=2\E7:rc=2\E8:cs=5\E[%i%d;%dr:UP=2\E[%dA:DO=2\E[%dB:RI=2\E[%dC:LE=2\E[%dD:ct=2\E[3g:st=2\EH:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:RA=\E[?7l:SA=\E[?7h: xterm:li#65:kh=\EOH:@7=\EOF:kb=^H:kD=^?:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:rs=\E>\E[?1;3;4;5l\E[?7;8h:ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:LE=\E[%dD:ct=\E[3g:st=\EH:tc=vt100: cons25:ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263n\305`^Da\260f\370g\361~\371.^Y-^Xh\261i^U0\333y\363z\362:al=\E[L:am:bs:NP:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:dc=\E[P:dl=\E[M:do=\E[B:bt=\E[Z:ho=\E[H:ic=\E[@:li#25:cb=\E[1K:ms:nd=\E[C:pt:rs=\E[x\E[m\Ec:so=\E[7m:se=\E[m:up=\E[A:pa#64:Co#8:AF=\E[3%dm:AB=\E[4%dm:op=\E[x:sc=\E7:rc=\E8:kb=^H:kh=\E[H:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:le=^H:eo:sf=\E[S:sr=\E[T:IC=\E[%d@:DC=\E[%dP:SF=\E[%dS:SR=\E[%dT:AL=\E[%dL:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:cv=\E[%i%dd:ch=\E[%i%d`:bw:mb=\E[5m:md=\E[1m:mh=\E[30;1m:mr=\E[7m:me=\E[m:bl=^G:ut:it#8:km: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 4:23:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (mobile.wemm.org [202.12.86.17]) by hub.freebsd.org (Postfix) with ESMTP id 566AD37B479 for ; Thu, 9 Nov 2000 04:23:41 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eA9CNQW26294; Thu, 9 Nov 2000 20:23:27 +0800 (WST) (envelope-from peter@netplex.com.au) Message-Id: <200011091223.eA9CNQW26294@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011090249.TAA35455@harmony.village.org> Date: Thu, 09 Nov 2000 20:23:26 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > : I have a patch that makes /bin and /sbin optionally non-static. For > : small systems that have / and /usr on the same file system, you can > : save about 5M-6M of disk space by making /bin and /sbin shared. > > It looks like I understated the savings. It saves 6.5M for our cut > down tree (which tries to grab as few of the /bin and /sbin binaries > as it can). For the full tree it saves 12-13M (2.1M vs 14.4M). My > cut down minimal system went from 14.7M to 8.2M. I have often wondered exactly what it would take to make a truely shareable / without /usr mounted and actually work properly.. As I see it: - /usr/libexec/ld-elf.so.1 would have to move to / somewhere. - The ldscripts would need /lib:/usr/lib instead of just /usr/lib for their paths - ld-elf.so.1 would have to know that /lib comes before /usr/lib, etc. - we'd need a selection of .so's in /lib so that /bin and /sbin could be useable. - The gcc specs would need a couple of tweaks. *then* nsswitch becomes useful so that /bin/ls can dlopen() the .so's for true plugin name resolvers etc. And /bin/sh can do a 'cd ~user' for something like nisplus which will never fit inside libc.so.x. I've tinkered with this before and got it almost to the point of working but got distracted and worked on something else instead. Moving libc, libm, and some others (eg: libcurses) to /lib ate back some of the originally saved space, but overall it was still *way* in front for disk space. 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 From owner-freebsd-arch Thu Nov 9 5: 8:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0019437B4C5 for ; Thu, 9 Nov 2000 05:08:13 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA64047; Thu, 9 Nov 2000 14:07:53 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Wemm Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> From: Dag-Erling Smorgrav Date: 09 Nov 2000 14:07:52 +0100 In-Reply-To: Peter Wemm's message of "Thu, 09 Nov 2000 20:23:26 +0800" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > I have often wondered exactly what it would take to make a truely shareable > / without /usr mounted and actually work properly.. If you want Solaris, you know where to find it. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 5:56:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id A7B7437B479 for ; Thu, 9 Nov 2000 05:56:46 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13tsBr-0000rH-00; Thu, 09 Nov 2000 15:56:31 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id PAA13914; Thu, 9 Nov 2000 15:56:39 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 13814; Thu Nov 9 15:55:16 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13tsAd-0004Ba-00; Thu, 09 Nov 2000 15:55:15 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: Peter Wemm , Warner Losh , arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "09 Nov 2000 14:07:52 +0100." Date: Thu, 09 Nov 2000 15:55:15 +0200 Message-ID: <16093.973778115@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09 Nov 2000 14:07:52 +0100, Dag-Erling Smorgrav wrote: > > I have often wondered exactly what it would take to make a truely shareable > > / without /usr mounted and actually work properly.. > > If you want Solaris, you know where to find it. While this is a very clever response, I don't see how it contributes. Surely if people both think that this might come in handy _and_ are willing to do the work involved, it's worth letting them discuss and proceed unhindered? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 6:23:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5F2E737B479 for ; Thu, 9 Nov 2000 06:23:29 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA64337; Thu, 9 Nov 2000 15:23:19 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Sheldon Hearn Cc: Peter Wemm , Warner Losh , arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed References: <16093.973778115@axl.fw.uunet.co.za> From: Dag-Erling Smorgrav Date: 09 Nov 2000 15:23:19 +0100 In-Reply-To: Sheldon Hearn's message of "Thu, 09 Nov 2000 15:55:15 +0200" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > While this is a very clever response, I don't see how it contributes. > Surely if people both think that this might come in handy _and_ are > willing to do the work involved, it's worth letting them discuss and > proceed unhindered? As long as anybody who suggests making it the default is thoroughly thwacked, spanked, and accorded the privilege of unbuggering heaps of So-lart-us boxen with fubared linkers or libraries. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 7:16: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 29E0137B4CF for ; Thu, 9 Nov 2000 07:16:00 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13ttQX-0001or-00; Thu, 09 Nov 2000 17:15:45 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id RAA23275; Thu, 9 Nov 2000 17:15:53 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 23207; Thu Nov 9 17:15:07 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13ttPv-0004Ic-00; Thu, 09 Nov 2000 17:15:07 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: Peter Wemm , Warner Losh , arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "09 Nov 2000 15:23:19 +0100." Date: Thu, 09 Nov 2000 17:15:07 +0200 Message-ID: <16529.973782907@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09 Nov 2000 15:23:19 +0100, Dag-Erling Smorgrav wrote: > As long as anybody who suggests making it the default is thoroughly > thwacked, spanked, and accorded the privilege of unbuggering heaps of > So-lart-us boxen with fubared linkers or libraries. I'm sure that most folks agree with you. Even Warner, in his original post, was quite clear about this being an added extra, rather than the default. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 7:19:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CC12237B479 for ; Thu, 9 Nov 2000 07:19:16 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA64539; Thu, 9 Nov 2000 16:19:03 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Sheldon Hearn Cc: Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <16529.973782907@axl.fw.uunet.co.za> From: Dag-Erling Smorgrav Date: 09 Nov 2000 16:19:02 +0100 In-Reply-To: Sheldon Hearn's message of "Thu, 09 Nov 2000 17:15:07 +0200" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > On 09 Nov 2000 15:23:19 +0100, Dag-Erling Smorgrav wrote: > > As long as anybody who suggests making it the default is thoroughly > > thwacked, spanked, and accorded the privilege of unbuggering heaps of > > So-lart-us boxen with fubared linkers or libraries. > I'm sure that most folks agree with you. Even Warner, in his original > post, was quite clear about this being an added extra, rather than the > default. :-) I must have missed that part. Sorry for the disturbance :) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 8:30:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id C812A37B479 for ; Thu, 9 Nov 2000 08:30:04 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id JAA17561; Thu, 9 Nov 2000 09:26:37 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAlqaydI; Thu Nov 9 09:26:26 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id JAA20559; Thu, 9 Nov 2000 09:29:41 -0700 (MST) From: Terry Lambert Message-Id: <200011091629.JAA20559@usr08.primenet.com> Subject: Re: AIX SIGDANGER (was Re: softdep panic due to blocked malloc) To: keith.stevenson@louisville.edu (Keith Stevenson) Date: Thu, 9 Nov 2000 16:29:41 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dcs@newsguy.com (Daniel C. Sobral), arch@FreeBSD.ORG In-Reply-To: <20001108175704.B1405@osaka.louisville.edu> from "Keith Stevenson" at Nov 08, 2000 05:57:04 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is a bit offtopic, but I couldn't help myself. (I'm an AIX admin) > > Quoting IBM's July 2000 system documentation CDROM: [ ... SIGDANGER default action = ignore ... ] > So, SIGDANGER doesn't buy you much unless your applications have a handler for > it. (In my experience, most don't.) I was not very happy when I hit a low > memory situation and AIX started committing random acts of violence against > my process table. The system ended up being so hosed, I had to reboot to > maintenance mode and repair a bunch of datafiles. (One of our production > applications doesn't SIGKILL gracefully.) > > I think that SIGDANGER would make a lot more sense if its default action was > the same as SIGTERM. SIGKILL'ing everything in sight isn't a lot cleaner > (IMO) than letting the system crash. FWIW, the last time I played with this particular issue was on a machine with too little swap and no ability to set the swap as a hog partititon (one which would grow 4M at a time, until all unallocated PP's were allocated to it). At the time, I am almost dead certain that SIGDANGER would act as SIGTERM, not be ignored, by default. Unfortunately (or fortunately), I rather doubt anyone could dig up a copy of AIX 3.x to verify this, so if I'm wrong, I'm wrong. If I _am_ wrong, SIGDANGER is actually much more useful, IMO, in that it would alert processes to the "I'm about to start being violent". This wouldn't help programs that didn't set up their own handler to get them out of the blast radius, but on the other hand, it'd be a great incentive to set yourself up that way. The only problem with this, of course, is that programs well enough behaved to heed the warning are probably not the problems in the first place. It would be useful, instead, to change the kernel to commit "semi-random acts of violence": send SIGTERM in phases, and prefer to send it to programs _without_ a SIGDANGER handler. The problem with this, of course, is once the behaviour is known, programs that are badly behaved will just register handlers that do nothing, to keep themselves out of harm's way, and even a well behaved program could be the victim of a DOS or a bug, so it really does very little overall to "fix" things, except that it lets programs that take the trouble to do all the work actually shutdown gracefully. All in all, it's still not useful for a kernel startvation, and it's only barely useful as itself, and then only against unintentional attacks that don't intentionally mimic degenerate cases. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 8:48:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 56B9237B479 for ; Thu, 9 Nov 2000 08:48:25 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA03520; Thu, 9 Nov 2000 09:48:23 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id JAA16420; Thu, 9 Nov 2000 09:48:23 -0700 (MST) (envelope-from nate) Date: Thu, 9 Nov 2000 09:48:23 -0700 (MST) Message-Id: <200011091648.JAA16420@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011090155.SAA35024@harmony.village.org> References: <200011090155.SAA35024@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > > I have a patch that makes /bin and /sbin optionally non-static. For > small systems that have / and /usr on the same file system, you can > save about 5M-6M of disk space by making /bin and /sbin shared. > > Since this is undesirable for systems that have / and /usr on > different file systems, I thought I'd make an option. > > What should I call the option? > > I'm thinking SLASHED_SHARED, but that's a horrible name. ROOTBIN_SHARED? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11: 3:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5410437B4C5 for ; Thu, 9 Nov 2000 11:03:14 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA9J3Cg21440 for ; Thu, 9 Nov 2000 12:03:12 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43016 for ; Thu, 9 Nov 2000 12:03:11 -0700 (MST) Message-Id: <200011091903.MAA43016@harmony.village.org> To: arch@freebsd.org Subject: Silly question Date: Thu, 09 Nov 2000 12:03:11 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Now that the boot loader supports compressed kernels and has for some time, I was wondering why we don't gzip our kernels and kernel driver modules like we do man pages. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11: 6:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 70E0337B479 for ; Thu, 9 Nov 2000 11:06:31 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9J6Ms10566; Thu, 9 Nov 2000 11:06:22 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 11:06:22 -0800 (PST) From: Matt Dillon Message-Id: <200011091906.eA9J6Ms10566@earth.backplane.com> To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Silly question References: <200011091903.MAA43016@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Now that the boot loader supports compressed kernels and has for some :time, I was wondering why we don't gzip our kernels and kernel driver :modules like we do man pages. : :Warner Hmm. What about when libkvm needs to do a symbol lookup? Or the system needs to makes a crash dump? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:10:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 5A11037B4C5 for ; Thu, 9 Nov 2000 11:10:49 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9J9wM10639; Thu, 9 Nov 2000 11:09:58 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 11:09:58 -0800 (PST) From: Matt Dillon Message-Id: <200011091909.eA9J9wM10639@earth.backplane.com> To: Peter Wemm Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Warner Losh wrote: :> : I have a patch that makes /bin and /sbin optionally non-static. For :> : small systems that have / and /usr on the same file system, you can :> : save about 5M-6M of disk space by making /bin and /sbin shared. :> :> It looks like I understated the savings. It saves 6.5M for our cut :> down tree (which tries to grab as few of the /bin and /sbin binaries :> as it can). For the full tree it saves 12-13M (2.1M vs 14.4M). My :> cut down minimal system went from 14.7M to 8.2M. : :I have often wondered exactly what it would take to make a truely shareable :/ without /usr mounted and actually work properly.. : :As I see it: :- /usr/libexec/ld-elf.so.1 would have to move to / somewhere. :- The ldscripts would need /lib:/usr/lib instead of just /usr/lib for their :paths :- ld-elf.so.1 would have to know that /lib comes before /usr/lib, etc. :- we'd need a selection of .so's in /lib so that /bin and /sbin could be :useable. :- The gcc specs would need a couple of tweaks. : :*then* nsswitch becomes useful so that /bin/ls can dlopen() the .so's for :true plugin name resolvers etc. And /bin/sh can do a 'cd ~user' for something :like nisplus which will never fit inside libc.so.x. : :I've tinkered with this before and got it almost to the point of working but :got distracted and worked on something else instead. Moving libc, libm, and :some others (eg: libcurses) to /lib ate back some of the originally saved :space, but overall it was still *way* in front for disk space. : :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 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 also have unfond memories of blowing /lib up under linux and not being able to do anything. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:11: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2550B37B479 for ; Thu, 9 Nov 2000 11:11:04 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA9JB2g21483; Thu, 9 Nov 2000 12:11:02 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43086; Thu, 9 Nov 2000 12:11:02 -0700 (MST) Message-Id: <200011091911.MAA43086@harmony.village.org> To: Matt Dillon Subject: Re: Silly question Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Nov 2000 11:06:22 PST." <200011091906.eA9J6Ms10566@earth.backplane.com> References: <200011091906.eA9J6Ms10566@earth.backplane.com> <200011091903.MAA43016@harmony.village.org> Date: Thu, 09 Nov 2000 12:11:02 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011091906.eA9J6Ms10566@earth.backplane.com> Matt Dillon writes: : :Now that the boot loader supports compressed kernels and has for some : :time, I was wondering why we don't gzip our kernels and kernel driver : :modules like we do man pages. : : : :Warner : : Hmm. What about when libkvm needs to do a symbol lookup? Or : the system needs to makes a crash dump? ps, top and all that seems to work with a compressed kernel (just tried it). When the system makes a crash dump, doesn't it just splat memory into the swap partition in a rather stupid way? I don't know about other programs, but I do know that top just uses kvm_open to get its kernel variable needs met. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:15:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5D88537B479 for ; Thu, 9 Nov 2000 11:15:34 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA9JFWg21495; Thu, 9 Nov 2000 12:15:33 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43115; Thu, 9 Nov 2000 12:15:32 -0700 (MST) Message-Id: <200011091915.MAA43115@harmony.village.org> To: Matt Dillon Subject: Re: The shared /bin and /sbin bikeshed Cc: Peter Wemm , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Nov 2000 11:09:58 PST." <200011091909.eA9J9wM10639@earth.backplane.com> References: <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> Date: Thu, 09 Nov 2000 12:15:32 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011091909.eA9J9wM10639@earth.backplane.com> Matt Dillon writes: : 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 also : have unfond memories of blowing /lib up under linux and not being : able to do anything. In the general case I'd agree with you. Disk is cheap. And almost all system have split / and /usr. In the small, embedded world, however, reducing the 4.1M and 12M to 600k and 1200k respectively is a huge win. We at Timing Solutions run FreeBSD in 16M or 32M or 64M parts where an extra 6M is a huge win. Especially on the 16M part. The minimal system that I had went from 14.7M to 7.9M which pushed the 16M part from being useless to being useful (we have about 6M of binaries and sundries that go onto these systems). I also plan on putting together a small 16M X terminal for the iopener with this if all goes well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:20:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 3075737B479 for ; Thu, 9 Nov 2000 11:20:52 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9JKos10894; Thu, 9 Nov 2000 11:20:50 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 11:20:50 -0800 (PST) From: Matt Dillon Message-Id: <200011091920.eA9JKos10894@earth.backplane.com> To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Silly question References: <200011091906.eA9J6Ms10566@earth.backplane.com> <200011091903.MAA43016@harmony.village.org> <200011091911.MAA43086@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :ps, top and all that seems to work with a compressed kernel (just :tried it). When the system makes a crash dump, doesn't it just splat :memory into the swap partition in a rather stupid way? I don't know :about other programs, but I do know that top just uses kvm_open to get :its kernel variable needs met. : :Warner It sounds like it could be made to work. I don't think we should do it by default because you'd still have to gunzip the kernel to get anything useful out of it when working on crashdumps, but I can see a definite use for a kernel config option to install a compressed kernel. It's one of those things that would have mattered a few years ago, but isn't much of an issue now and will be even less of one in the future. In fact, something I think would be even more useful to those of us who debug crash dumps a lot would be to have a configuration option to install a full debug kernel in / rather then a stripped kernel, so the crash recovery code copies the full debug kernel into /var/crash. If I forget to copy it manually my crash dumps become useless (in regards to gdb'ing them) when I install new kernels. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:22:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 97AF937B479 for ; Thu, 9 Nov 2000 11:22:49 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9JMZR10926; Thu, 9 Nov 2000 11:22:35 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 11:22:35 -0800 (PST) From: Matt Dillon Message-Id: <200011091922.eA9JMZR10926@earth.backplane.com> To: Warner Losh Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091915.MAA43115@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200011091909.eA9J9wM10639@earth.backplane.com> Matt Dillon writes: :: 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 also :: have unfond memories of blowing /lib up under linux and not being :: able to do anything. : :In the general case I'd agree with you. Disk is cheap. And almost :all system have split / and /usr. : :In the small, embedded world, however, reducing the 4.1M and 12M to :600k and 1200k respectively is a huge win. We at Timing Solutions run :FreeBSD in 16M or 32M or 64M parts where an extra 6M is a huge win. :Especially on the 16M part. The minimal system that I had went from :14.7M to 7.9M which pushed the 16M part from being useless to being :useful (we have about 6M of binaries and sundries that go onto these :systems). : :I also plan on putting together a small 16M X terminal for the iopener :with this if all goes well. : :Warner Ah, for flash booting turnkey solutions... I see the benefit! But wouldn't something like /stand's all-in-one binary with hardlinks for most common boot/recovery options be an even better solution? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:23:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D61FE37B479 for ; Thu, 9 Nov 2000 11:23:38 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA9JNSV01166; Thu, 9 Nov 2000 11:23:28 -0800 (PST) Date: Thu, 9 Nov 2000 11:23:28 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001109112328.T5112@fw.wintelcom.net> References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011091909.eA9J9wM10639@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Nov 09, 2000 at 11:09:58AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [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 also > 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. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:34:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C248537B479 for ; Thu, 9 Nov 2000 11:34:08 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA9JY6g21572; Thu, 9 Nov 2000 12:34:07 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43258; Thu, 9 Nov 2000 12:34:06 -0700 (MST) Message-Id: <200011091934.MAA43258@harmony.village.org> To: Matt Dillon Subject: Re: The shared /bin and /sbin bikeshed Cc: Peter Wemm , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Nov 2000 11:22:35 PST." <200011091922.eA9JMZR10926@earth.backplane.com> References: <200011091922.eA9JMZR10926@earth.backplane.com> <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091915.MAA43115@harmony.village.org> Date: Thu, 09 Nov 2000 12:34:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011091922.eA9JMZR10926@earth.backplane.com> Matt Dillon writes: : Ah, for flash booting turnkey solutions... I see the benefit! But : wouldn't something like /stand's all-in-one binary with hardlinks : for most common boot/recovery options be an even better solution? Not always. While you tend to get the absolute smallest system that way, you do pay a price. They are a bit PITA to upgrade individual parts of the system in place (which is sometimes required). It is also harder to layer together different products that way since you pay a big price for each static binary you want to put on the disk. With shared libaries you just add the binaries. We also run to run the same binaries on different systems and don't want to have to regenerate one monolithic binary. And the size savings isn't that huge. It is for similar reasons that we don't do a compressed MFS image for the whole thing. Our volumes are not high enough to deal with those headaches. Also, we need as much ram as we can get for our apps. Some of our boards are maxed out right now. If our volumes were a lot higher, and our margings smaller, I'd likely be shooting at a 2M-4M PicoBSD image. Discounting the RAM issue. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:44:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7BBA037B479 for ; Thu, 9 Nov 2000 11:44:36 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id LAA24913; Thu, 9 Nov 2000 11:44:28 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id eA9JiSN30771; Thu, 9 Nov 2000 11:44:28 -0800 (PST) (envelope-from jdp) Date: Thu, 9 Nov 2000 11:44:28 -0800 (PST) Message-Id: <200011091944.eA9JiSN30771@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: bright@wintelcom.net Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <20001109112328.T5112@fw.wintelcom.net> References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20001109112328.T5112@fw.wintelcom.net>, Alfred Perlstein wrote: > 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. I don't understand this statement. If there is even a single dynamically linked application running, libc.so will already be in memory, and that image will be shared by whatever you're trying to run, e.g., "ps". True, only the text will be shared -- the data and bss will still require additional memory. However, the situation is even worse with a statically linked "ps". Assuming (reasonably) that there is no "ps" already running, the entire image will be unshared. In other words, it should take less memory to run the shared version than the statically linked version. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 11:50:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B171937B479 for ; Thu, 9 Nov 2000 11:50:24 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA9JoNl02272 for arch@freebsd.org; Thu, 9 Nov 2000 11:50:23 -0800 (PST) Date: Thu, 9 Nov 2000 11:50:23 -0800 From: Alfred Perlstein To: arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001109115022.Y5112@fw.wintelcom.net> References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> <200011091944.eA9JiSN30771@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011091944.eA9JiSN30771@vashon.polstra.com>; from jdp@polstra.com on Thu, Nov 09, 2000 at 11:44:28AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [001109 11:44] wrote: > In article <20001109112328.T5112@fw.wintelcom.net>, Alfred Perlstein > wrote: > > > 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. > > I don't understand this statement. If there is even a single > dynamically linked application running, libc.so will already be in > memory, and that image will be shared by whatever you're trying to > run, e.g., "ps". True, only the text will be shared -- the data and > bss will still require additional memory. However, the situation is > even worse with a statically linked "ps". Assuming (reasonably) that > there is no "ps" already running, the entire image will be unshared. > In other words, it should take less memory to run the shared version > than the statically linked version. A lot of things in Linux defy explanation, all I know is what I saw, which was root being unable to run 'ps' or 'kill' and the error was that there wasn't enough free memory to map in libc.so. The really strange part was that root was able to log in, but yet unable to do anything else. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 14:12:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 5CDE637B4C5; Thu, 9 Nov 2000 14:12:34 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp246.osd.bsdi.com [204.216.28.246]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eA9MCNH41816; Thu, 9 Nov 2000 14:12:23 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011090305.eA935W900472@mass.osd.bsdi.com> Date: Thu, 09 Nov 2000 14:12:54 -0800 (PST) From: John Baldwin To: Mike Smith Subject: Re: The shared /bin and /sbin bikeshed Cc: arch@FreeBSD.org, Warner Losh , Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Nov-00 Mike Smith wrote: >> > What should I call the option? >> > >> > I'm thinking SLASHED_SHARED, but that's a horrible name. >> > >> > I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too >> > long > > NO_STATIC_BINARIES > NO_STATIC_LIBRARIES > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force > people to change) I second these names. /me puts away his paintbrush... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 14:35:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id F0BC937B479 for ; Thu, 9 Nov 2000 14:35:35 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA9Meu903694; Thu, 9 Nov 2000 14:40:58 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011092240.eA9Meu903694@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: Matt Dillon , Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Thu, 09 Nov 2000 11:23:28 PST." <20001109112328.T5112@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Nov 2000 14:40:56 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Matt Dillon [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 also > > 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. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 14:47:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DCD6837B4C5; Thu, 9 Nov 2000 14:47:47 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA9MllN09692; Thu, 9 Nov 2000 14:47:47 -0800 (PST) Date: Thu, 9 Nov 2000 14:47:47 -0800 From: Alfred Perlstein To: Mike Smith Cc: Matt Dillon , Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001109144747.E5112@fw.wintelcom.net> References: <20001109112328.T5112@fw.wintelcom.net> <200011092240.eA9Meu903694@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011092240.eA9Meu903694@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Thu, Nov 09, 2000 at 02:40:56PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith [001109 14:35] wrote: > > * Matt Dillon [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 also > > > 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. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 14:52:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id C9DA337B479 for ; Thu, 9 Nov 2000 14:52:11 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA9Mvq903776; Thu, 9 Nov 2000 14:57:52 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011092257.eA9Mvq903776@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Thu, 09 Nov 2000 14:47:47 PST." <20001109144747.E5112@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Nov 2000 14:57:52 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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. No, but it does mean that what "did" happen for you on a Linux system is unlikely to be representative of what will happen under similar circumstances on a FreeBSD system, and thus your use of it as an argument against doing this is entirely invalid. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:12:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id D20CE37B4CF; Thu, 9 Nov 2000 15:12:38 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id AAA61220; Fri, 10 Nov 2000 00:12:36 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id AAA25171; Fri, 10 Nov 2000 00:12:36 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 10 Nov 2000 00:12:36 +0100 (CET) From: Marius Bendiksen To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. In-Reply-To: <28041.973635706@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sounds good to me, but I have a small alteration to suggest. You might want to introduce the color ORANGE, instead of yellow, and have yellow and green be per-subsystem states, and orange and red be global, so as to be able to adapt more gradually to the impending highwatermark. Also, I'd suggest going through with the idea of posting signals to user processes before hitting a real high water mark, preferrably also color coded, as opposed to SIGDANGER, which I don't see as much use in. The use of color, however, when extended into userland, allows software doing clustering and such to signal that the other hosts in the cluster should cover for it, and that it does not want any more load. The use of a black or green signal (depending on granularity) to say "act normal" prevents severe DoS attacks, I think. --- Marius Bendiksen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:20:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id AF50537B4C5; Thu, 9 Nov 2000 15:20:17 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id AAA62828; Fri, 10 Nov 2000 00:20:15 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id AAA25192; Fri, 10 Nov 2000 00:20:15 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 10 Nov 2000 00:20:15 +0100 (CET) From: Marius Bendiksen To: Bill Fumerola Cc: Andre Oppermann , Paul Saab , Poul-Henning Kamp , arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. In-Reply-To: <20001107192754.Y37870@jade.chc-chimes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think that a subsystem variable could have value, but there are portions > of the kernel that an attack on one subsystem has a large effect on others. Hence semishared state, as per my suggestion. Use green (per-subsystem), yellow (per-subsystem), orange (global), read (global), panic. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:22:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id A844337B479; Thu, 9 Nov 2000 15:22:18 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9NMHN12920; Thu, 9 Nov 2000 15:22:17 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 15:22:17 -0800 (PST) From: Matt Dillon Message-Id: <200011092322.eA9NMHN12920@earth.backplane.com> To: Mike Smith Cc: Alfred Perlstein , Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011092240.eA9Meu903694@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. This is not exactly true. The difference between the static binary and shared binary is that *ALL* the text pages in the static binary are clean. A shared binary dirties many, many more pages to generate the library relocations - as much as 60K for a simple program that links into libc. So in a low memory situation the static binary will win, because clean pages use the already-existing binary file image as backing store and do not have to go to swap. They can simply be discarded. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:42:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 4C96237B479 for ; Thu, 9 Nov 2000 15:42:54 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id AAA66786; Fri, 10 Nov 2000 00:42:38 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id AAA25301; Fri, 10 Nov 2000 00:42:37 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 10 Nov 2000 00:42:37 +0100 (CET) From: Marius Bendiksen To: Matt Dillon Cc: Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011091909.eA9J9wM10639@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > /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 Actually, for embedded applications, you need the disk space. With the above definition of "fairly small", you'd have a hard time fitting a basic install on a 16m flash. > /bin and /sbin have saved me more times then I can remember. I also > have unfond memories of blowing /lib up under linux and not being > able to do anything. Bootfs sort of solves this, in that you could optionally build your bootfs to contain fixit tools, and fall back to this if init fails to resolve its symbols and all that. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:44:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3188137B4C5; Thu, 9 Nov 2000 15:44:25 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eA9NiOP11402; Thu, 9 Nov 2000 15:44:24 -0800 (PST) Date: Thu, 9 Nov 2000 15:44:24 -0800 From: Alfred Perlstein To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001109154424.F5112@fw.wintelcom.net> References: <20001109144747.E5112@fw.wintelcom.net> <200011092257.eA9Mvq903776@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011092257.eA9Mvq903776@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Thu, Nov 09, 2000 at 02:57:52PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith [001109 14:52] wrote: > > > > 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. > > No, but it does mean that what "did" happen for you on a Linux system is > unlikely to be representative of what will happen under similar > circumstances on a FreeBSD system, and thus your use of it as an argument > against doing this is entirely invalid. Sheesh Mike, I wasn't arguing against it, I was dissing on Linux. But still, even with shared code, the shared libraries demand: ~/src/share/man/man3 % size /usr/lib/libc.so text data bss dec hex filename 509098 15104 78200 602402 93122 /usr/lib/libc.so .(15:41:45)(bright@kyle.wintelcom.net) ~/src/share/man/man3 % size /bin/ps text data bss dec hex filename 184333 9928 37456 231717 38925 /bin/ps I may be misinterpreting this output, but it looks like if you ever mod FreeBSD to allow for disallowing of overcommit you might not have fun in low memory situations because of the BSS and DATA requirements needed for libc. (?) Anyhow, I'm not really arguing for or against, just bringing up some amusing experiances some coworkers had to deal with when using Linux and dynamic /. I really don't have much of a problem with a dynamic / since we already have /stand. Although /stand might need some new programs added to compensate, or a counterpart that gets updated as part of the installworld target. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 15:46: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 3F14537B479; Thu, 9 Nov 2000 15:46:03 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id AAA67464; Fri, 10 Nov 2000 00:46:02 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id AAA25315; Fri, 10 Nov 2000 00:46:02 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 10 Nov 2000 00:46:02 +0100 (CET) From: Marius Bendiksen To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > NO_STATIC_BINARIES > > NO_STATIC_LIBRARIES > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force > > people to change) > I second these names. AOL. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 19:26:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 699B137B4C5 for ; Thu, 9 Nov 2000 19:26:13 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAA3Q6015450; Thu, 9 Nov 2000 19:26:06 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 19:26:06 -0800 (PST) From: Matt Dillon Message-Id: <200011100326.eAA3Q6015450@earth.backplane.com> To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :A lot of things in Linux defy explanation, all I know is what I :saw, which was root being unable to run 'ps' or 'kill' and the :error was that there wasn't enough free memory to map in libc.so. : :The really strange part was that root was able to log in, but :yet unable to do anything else. : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Linking with a shared library eats memory at run time. It's that simple. Shared libraries make life easier but they do *NOT* generally reduce the run time in-core memory footprint of a machine. Dynamic executables actually increase the number of dirty pages the system has to cope with, at least for discretely-run programs, and they tend to force the entire shared library into core. Its a wash for programs that fork since the library relocations have already been done by the time you get to the fork, thus all the forked copies share the original parent's dirty library relocation pages. Don't forget that even static images can be demand-paged, and for a static image paging equates to simply throwing the page away since it is always clean. Demand-paging a dynamic binary requires writing some of those pages to swap due to the dynamic relocation, and each instance of the binary (when exec'd independantly) have their own private set of dirty pages to page out. So it makes a lot of sense for a dynamic binary to fall over in an extreme memory situation on a linux box when a static binary might not. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 21:57:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 781A337B479 for ; Thu, 9 Nov 2000 21:57:52 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13u7Cb-0000SV-00; Thu, 09 Nov 2000 22:58:17 -0700 Message-ID: <3A0B8E79.2B16E11@softweyr.com> Date: Thu, 09 Nov 2000 22:58:17 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Peter Wemm , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon 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! Speak for yourself, disk-boy. ;^) Recall Warner was talking about FLASH configurations. Checked the difference between 8MB and 16MB CF parts lately? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 9 22:43:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sydney.worldwide.lemis.com (earth.elinux.com.sg [203.120.99.101]) by hub.freebsd.org (Postfix) with ESMTP id AEA5037B479 for ; Thu, 9 Nov 2000 22:43:30 -0800 (PST) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.11.0/8.9.3) id eAA6gsC01786; Fri, 10 Nov 2000 14:42:54 +0800 (SGT) (envelope-from grog) Date: Fri, 10 Nov 2000 14:42:54 +0800 From: Greg Lehey To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001110144254.B1686@sydney.worldwide.lemis.com> References: <200011090155.SAA35024@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200011090155.SAA35024@harmony.village.org>; from imp@village.org on Wed, Nov 08, 2000 at 06:55:29PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 8 November 2000 at 18:55:29 -0700, Warner Losh wrote: > > I have a patch that makes /bin and /sbin optionally non-static. For > small systems that have / and /usr on the same file system, you can > save about 5M-6M of disk space by making /bin and /sbin shared. > > Since this is undesirable for systems that have / and /usr on > different file systems, I thought I'd make an option. > > What should I call the option? > > I'm thinking SLASHED_SHARED, but that's a horrible name. > > I've already rejected DANGEROUS_SBIN_BIN_SHARED_OPTION as being too > long I have opinions on this matter (of course :-), but I don't have time to discuss them. Once the shed is painted, could you post a summary? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 0:59:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 91F8C37B479 for ; Fri, 10 Nov 2000 00:59:46 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAA8xjg24590; Fri, 10 Nov 2000 01:59:45 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA47613; Fri, 10 Nov 2000 01:59:44 -0700 (MST) Message-Id: <200011100859.BAA47613@harmony.village.org> To: Greg Lehey Subject: Re: The shared /bin and /sbin bikeshed Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 10 Nov 2000 14:42:54 +0800." <20001110144254.B1686@sydney.worldwide.lemis.com> References: <20001110144254.B1686@sydney.worldwide.lemis.com> <200011090155.SAA35024@harmony.village.org> Date: Fri, 10 Nov 2000 01:59:44 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001110144254.B1686@sydney.worldwide.lemis.com> Greg Lehey writes: : I have opinions on this matter (of course :-), but I don't have time : to discuss them. Once the shed is painted, could you post a summary? Sure. I've added an option called DYNAMIC_ROOT_BINS. When it is defined and not NO, then /bin and /sbin, as represented by src/{sbin,bin}, will be built shared. I'll be committing it shortly. Mike also suggested a NO_STATIC_LIBRARIES. An idea I like, but will leave unimplemented for a time. Lots of other discussions that weren't on topic for my needs also happened. Much of it was interesting, but is left unsummarized here. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 1:14:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3CB3537B479; Fri, 10 Nov 2000 01:14:11 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA68184; Fri, 10 Nov 2000 10:14:06 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Baldwin Cc: Mike Smith , arch@FreeBSD.ORG, Warner Losh , Alfred Perlstein Subject: Re: The shared /bin and /sbin bikeshed References: From: Dag-Erling Smorgrav Date: 10 Nov 2000 10:14:05 +0100 In-Reply-To: John Baldwin's message of "Thu, 09 Nov 2000 14:12:54 -0800 (PST)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin writes: > > NO_STATIC_BINARIES > > NO_STATIC_LIBRARIES > > [and NO_PROFILED_LIBRARIES] > I second these names. I third them. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 1:27:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4BE9837B4C5; Fri, 10 Nov 2000 01:27:33 -0800 (PST) Received: from newsguy.com (p38-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.39]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id SAA06000; Fri, 10 Nov 2000 18:27:30 +0900 (JST) Message-ID: <3A0BBD01.ED1EF33E@newsguy.com> Date: Fri, 10 Nov 2000 18:16:49 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: John Baldwin Cc: Mike Smith , arch@FreeBSD.ORG, Warner Losh , Alfred Perlstein Subject: Re: The shared /bin and /sbin bikeshed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > > NO_STATIC_BINARIES > > NO_STATIC_LIBRARIES > > > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force > > people to change) > > I second these names. Actually, the _p libraries haven't been "profiled". They are "profile" libraries, in that they are used for "profiling". So, NO_PROFILE_LIBRARIES, please. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@world.wide.bsdconspiracy.net He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 1:38:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3115137B479; Fri, 10 Nov 2000 01:38:45 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAA9cfg24810; Fri, 10 Nov 2000 02:38:42 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA48105; Fri, 10 Nov 2000 02:38:41 -0700 (MST) Message-Id: <200011100938.CAA48105@harmony.village.org> To: "Daniel C. Sobral" Subject: Re: The shared /bin and /sbin bikeshed Cc: John Baldwin , Mike Smith , arch@FreeBSD.ORG, Alfred Perlstein In-reply-to: Your message of "Fri, 10 Nov 2000 18:16:49 +0900." <3A0BBD01.ED1EF33E@newsguy.com> References: <3A0BBD01.ED1EF33E@newsguy.com> Date: Fri, 10 Nov 2000 02:38:41 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A0BBD01.ED1EF33E@newsguy.com> "Daniel C. Sobral" writes: : John Baldwin wrote: : > : > > NO_STATIC_BINARIES : > > NO_STATIC_LIBRARIES : > > : > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force : > > people to change) : > : > I second these names. : : Actually, the _p libraries haven't been "profiled". They are "profile" : libraries, in that they are used for "profiling". So, : NO_PROFILE_LIBRARIES, please. BTW, I don't like NO_STATIC_BINARIES because that implies no static binaries anywhere, while my patch specifically just does /bin and /sbin. I didn't want to do that globally because I didn't want jdp to yell at me for making ld.so dynamic :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 1:53:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id A7E2437B479; Fri, 10 Nov 2000 01:53:42 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAA9xJ905757; Fri, 10 Nov 2000 01:59:19 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011100959.eAA9xJ905757@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: "Daniel C. Sobral" , John Baldwin , Mike Smith , arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Fri, 10 Nov 2000 02:38:41 MST." <200011100938.CAA48105@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Nov 2000 01:59:19 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <3A0BBD01.ED1EF33E@newsguy.com> "Daniel C. Sobral" writes: > : John Baldwin wrote: > : > > : > > NO_STATIC_BINARIES > : > > NO_STATIC_LIBRARIES > : > > > : > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force > : > > people to change) > : > > : > I second these names. > : > : Actually, the _p libraries haven't been "profiled". They are "profile" > : libraries, in that they are used for "profiling". So, > : NO_PROFILE_LIBRARIES, please. > > BTW, I don't like NO_STATIC_BINARIES because that implies no static > binaries anywhere, while my patch specifically just does /bin and > /sbin. I didn't want to do that globally because I didn't want jdp to > yell at me for making ld.so dynamic :-) I think "NO_STATIC_BINARIES" should make everything dynamic that can be made dynamic, so your limited functionality change is probably right. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 2:29:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id D397E37B4CF for ; Fri, 10 Nov 2000 02:28:59 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13uBQK-0004Mu-00; Fri, 10 Nov 2000 12:28:44 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id MAA26373; Fri, 10 Nov 2000 12:28:50 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 26091; Fri Nov 10 12:28:10 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13uBPm-0006MY-00; Fri, 10 Nov 2000 12:28:10 +0200 From: Sheldon Hearn To: Matt Dillon Cc: Peter Wemm , Warner Losh , arch@freebsd.org Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Thu, 09 Nov 2000 11:09:58 PST." <200011091909.eA9J9wM10639@earth.backplane.com> Date: Fri, 10 Nov 2000 12:28:10 +0200 Message-ID: <24461.973852090@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 09 Nov 2000 11:09:58 PST, Matt Dillon wrote: > I'd recommend against the linux /lib + /usr/lib model, it's a big > mess. I agree. In the kind of embedded system that Warner's doing all of this for, it seems to me that having binaries in /bin and /sbin linked against libraries in /usr/lib is no major transmash, since all three are more than likely to be on the same partition. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 2:37:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0B1AD37B479; Fri, 10 Nov 2000 02:37:30 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id VAA21439; Fri, 10 Nov 2000 21:37:18 +1100 Date: Fri, 10 Nov 2000 21:37:42 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Marius Bendiksen Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Nov 2000, Marius Bendiksen wrote: > > > NO_STATIC_BINARIES > > > NO_STATIC_LIBRARIES > > > (and obviously NOPROFILE -> NO_PROFILED_LIBRARIES with a hook to force > > > people to change) > > I second these names. > AOL. Even more obviously: NOPIC -> NO_POSITION_INDEPENDENT_CODE_LIBRARIES FreeBSD -> Free_Berkeley_Software_Distribution Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 2:38:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id E1DF937B479 for ; Fri, 10 Nov 2000 02:38:41 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAAAdom15384; Fri, 10 Nov 2000 02:39:50 -0800 (PST) (envelope-from kris) Date: Fri, 10 Nov 2000 02:39:50 -0800 From: Kris Kennaway To: Matt Dillon Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: Silly question Message-ID: <20001110023950.A15361@citusc17.usc.edu> References: <200011091906.eA9J6Ms10566@earth.backplane.com> <200011091903.MAA43016@harmony.village.org> <200011091911.MAA43086@harmony.village.org> <200011091920.eA9JKos10894@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011091920.eA9JKos10894@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Nov 09, 2000 at 11:20:50AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 09, 2000 at 11:20:50AM -0800, Matt Dillon wrote: > It sounds like it could be made to work. I don't think we should > do it by default because you'd still have to gunzip the kernel to > get anything useful out of it when working on crashdumps, but I can > see a definite use for a kernel config option to install a compressed > kernel. It's one of those things that would have mattered a few years > ago, but isn't much of an issue now and will be even less of one in= =20 > the future. I have a couple of machines with root filesystems that were created several geological ages ago, and now are continually running out of space because of general / bloat in the intervening millenia. I forgot about the ability to compress kernels..this would help me (and perhaps others) Kris --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjoL0HYACgkQWry0BWjoQKU0TACgmG0ENVSLtM0JuwI6uAXLyIS1 HEAAoOy4ZX9Uqw11yaMUxG31dszQaYYX =9cHW -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 2:54:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id AFE2B37B4C5; Fri, 10 Nov 2000 02:54:19 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAAAtMW15420; Fri, 10 Nov 2000 02:55:22 -0800 (PST) (envelope-from kris) Date: Fri, 10 Nov 2000 02:55:22 -0800 From: Kris Kennaway To: Mike Smith Cc: Warner Losh , "Daniel C. Sobral" , John Baldwin , arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001110025522.B15361@citusc17.usc.edu> References: <200011100938.CAA48105@harmony.village.org> <200011100959.eAA9xJ905757@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011100959.eAA9xJ905757@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Fri, Nov 10, 2000 at 01:59:19AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 10, 2000 at 01:59:19AM -0800, Mike Smith wrote: > I think "NO_STATIC_BINARIES" should make everything dynamic that can be= =20 > made dynamic, so your limited functionality change is probably right. Can I just chime in and say that statically linked binaries suck because they can be impossible to scan for when a library they were linked against has a bug or security vulnerability. Often you can be lucky and find a magic string in the binary which unambiguously shows whether or not it was linked against a vulnerable version (e.g. a RCS ID), but sometimes you have nothing to go on and it's hard to work out whether the binary was even linked against the library, let alone a vulnerable version thereof. Adding RCS IDs to all the source code files in the FreeBSD libraries (conditional on a compile-time anti-bloat option, e.g. buried in a macro) would fix this. Kris --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjoL1BkACgkQWry0BWjoQKV2YACg1iFUBOR/6vWsJZRaycoBtbDB BtUAoJeWTJc1fTsXbFGIZ2grICsALZ3f =3nIX -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 2:56: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1F08B37B479 for ; Fri, 10 Nov 2000 02:56:04 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA68686; Fri, 10 Nov 2000 11:55:59 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matt Dillon Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: Silly question References: <200011091906.eA9J6Ms10566@earth.backplane.com> <200011091903.MAA43016@harmony.village.org> <200011091911.MAA43086@harmony.village.org> <200011091920.eA9JKos10894@earth.backplane.com> From: Dag-Erling Smorgrav Date: 10 Nov 2000 11:55:59 +0100 In-Reply-To: Matt Dillon's message of "Thu, 9 Nov 2000 11:20:50 -0800 (PST)" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > It sounds like it could be made to work. I don't think we should > do it by default because you'd still have to gunzip the kernel to > get anything useful out of it when working on crashdumps, [...] Nah, just teach gdb to read gzipped binaries and dumps :) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 5:19:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (mobile.wemm.org [202.12.86.17]) by hub.freebsd.org (Postfix) with ESMTP id 26AAC37B479; Fri, 10 Nov 2000 05:19:07 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eAADImW34016; Fri, 10 Nov 2000 21:18:49 +0800 (WST) (envelope-from peter@netplex.com.au) Message-Id: <200011101318.eAADImW34016@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alfred Perlstein Cc: Mike Smith , Matt Dillon , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <20001109144747.E5112@fw.wintelcom.net> Date: Fri, 10 Nov 2000 21:18:48 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Mike Smith [001109 14:35] wrote: > > > * Matt Dillon [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 From owner-freebsd-arch Fri Nov 10 5:40:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (mobile.wemm.org [202.12.86.17]) by hub.freebsd.org (Postfix) with ESMTP id E815937B479; Fri, 10 Nov 2000 05:40:25 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eAADeEW34342; Fri, 10 Nov 2000 21:40:15 +0800 (WST) (envelope-from peter@netplex.com.au) Message-Id: <200011101340.eAADeEW34342@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matt Dillon Cc: Mike Smith , Alfred Perlstein , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011092322.eA9NMHN12920@earth.backplane.com> Date: Fri, 10 Nov 2000 21:40:14 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > :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. > > This is not exactly true. The difference between the static binary and > shared binary is that *ALL* the text pages in the static binary are > clean. A shared binary dirties many, many more pages to generate the > library relocations - as much as 60K for a simple program that links > into libc. Text in a shared binary (and library) is clean too. All references go via the PLT and GOT.. and *they* are what get relocated and backed by swap. The more relocations, the larger this will be. > So in a low memory situation the static binary will win, because clean > pages use the already-existing binary file image as backing store and > do not have to go to swap. They can simply be discarded. *A* static binary, yes. If you are only using the one binary for all processes. I doubt many real-world out-of-memory situations are all due to a a single static vs. dynamic 'ps' binary shared 300+ times.... More likely it'd be a runaway httpd or something, which are almost always shared anyway. Trying to run a static ps is going to need ~330K of ram. Trying to run a dyanmic ps is going to need ~25K of ram for the text+data and ~60K or so for the PLT/GOT glue, plus it will hook onto the already-present libc.so pages for text and COW any libc.so data pages... 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 From owner-freebsd-arch Fri Nov 10 7:48: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7630537B4C5; Fri, 10 Nov 2000 07:47:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id CAA02373; Sat, 11 Nov 2000 02:47:38 +1100 Date: Sat, 11 Nov 2000 02:48:24 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: Alfred Perlstein , Mike Smith , Matt Dillon , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011101318.eAADImW34016@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Nov 2000, Peter Wemm wrote: > 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. This depends on the process mix. For processes that have a few forked copies running concurrently, static linkage takes more memory because the process text is shared and the process data and mapping overheads are much smaller than for shared linkage (libc has poor locality...). I used to use shared linkage for everything until I understood this point. Now I use static linkage for everything except perl and ports. This is faster, and seems to take about the same amount of memory for my process mix. It takes slightly more than 2 cents worth of disk space. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 8:44:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 6AC5337B479; Fri, 10 Nov 2000 08:44:12 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAAGhaf18348; Fri, 10 Nov 2000 08:43:36 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Nov 2000 08:43:36 -0800 (PST) From: Matt Dillon Message-Id: <200011101643.eAAGhaf18348@earth.backplane.com> To: Peter Wemm Cc: Mike Smith , Alfred Perlstein , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011101340.eAADeEW34342@mobile.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Text in a shared binary (and library) is clean too. All references go :via the PLT and GOT.. and *they* are what get relocated and backed by swap. :The more relocations, the larger this will be. : :> So in a low memory situation the static binary will win, because clean :> pages use the already-existing binary file image as backing store and :> do not have to go to swap. They can simply be discarded. : :*A* static binary, yes. If you are only using the one binary for all :processes. I doubt many real-world out-of-memory situations are all due :to a a single static vs. dynamic 'ps' binary shared 300+ times.... :More likely it'd be a runaway httpd or something, which are almost always :shared anyway. Trying to run a static ps is going to need ~330K of ram. :Trying to run a dyanmic ps is going to need ~25K of ram for the text+data :and ~60K or so for the PLT/GOT glue, plus it will hook onto the already-present :libc.so pages for text and COW any libc.so data pages... : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au Lets test this: stty tostop 0 3 0 27880 11328 6 0 0 0 35 0 0 0 631 648 217 2 2 97 0 3 0 26064 11328 3 0 0 0 0 0 2 0 614 317 129 1 2 98 ps & 0 3 0 31912 11188 3 0 0 0 0 0 0 0 609 364 147 0 2 98 1 3 0 29848 11188 7 0 0 0 0 0 0 0 617 448 140 1 2 97 static ps binary takes 11328 - 11188 = 140KB of ram -- (cd into /usr/obj/..., relink ps without the -static) procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ac0 in sy cs us sy id 0 3 0 28840 9444 9 0 0 0 6 0 0 0 608 325 131 2 2 97 0 3 0 28840 9444 14 0 0 0 6 0 0 0 623 410 153 0 2 98 ps & 0 3 0 25896 9232 176 0 0 0 81 0 0 0 613 541 155 1 3 96 1 3 0 25896 9232 10 0 0 0 6 0 0 0 620 460 174 1 2 98 kill %1 0 3 0 25580 9440 21 0 0 0 64 0 0 0 623 518 178 2 2 96 dynamic ps binary takes 9444-9232 = 212KB of ram. This is on a normal system, running normal processes. I have a vmstat running in one window, I run 'ps' in the other and then kill it. I do this a couple of times to be sure it's only the ps that is showing up in the vmstat memory utilization. Despite the fact that the dynamic 'ps' has access to the shared libc library which is already mostly in core, the dynamic 'ps' still eats an extra 72KB of memory. Now, I realize that this isn't a perfect test -- but it does demonstrate my point quite well I think. You are welcome to run your own tests, Peter. People seems to have gotten into their heads that dynamic binaries take up less memory because they 'appear' to be smaller, but that simply is not the case in most situations. Dynamic binaries save disk space. They generally do not save ram. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 8:51: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9C76137B4C5 for ; Fri, 10 Nov 2000 08:51:05 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id JAA09425; Fri, 10 Nov 2000 09:47:04 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAYwaars; Fri Nov 10 09:46:52 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id JAA20567; Fri, 10 Nov 2000 09:50:43 -0700 (MST) From: Terry Lambert Message-Id: <200011101650.JAA20567@usr08.primenet.com> Subject: Re: The shared /bin and /sbin bikeshed To: dillon@earth.backplane.com (Matt Dillon) Date: Fri, 10 Nov 2000 16:50:43 +0000 (GMT) Cc: peter@netplex.com.au (Peter Wemm), imp@village.org (Warner Losh), arch@FreeBSD.ORG In-Reply-To: <200011091909.eA9J9wM10639@earth.backplane.com> from "Matt Dillon" at Nov 09, 2000 11:09:58 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 also > have unfond memories of blowing /lib up under linux and not being > able to do anything. I had a similar experience with FreeBSD, when the kernel.ko stuff went in, and when I accidently trashed /kernel. If there is a single point of failure, there's a single point of failure, and avoiding the /lib + /usr/lib model won't get rid of the fact. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 8:54:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 9C4DC37B479 for ; Fri, 10 Nov 2000 08:54:20 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAAGsGu18423; Fri, 10 Nov 2000 08:54:16 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Nov 2000 08:54:16 -0800 (PST) From: Matt Dillon Message-Id: <200011101654.eAAGsGu18423@earth.backplane.com> To: Terry Lambert Cc: peter@netplex.com.au (Peter Wemm), imp@village.org (Warner Losh), arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011101650.JAA20567@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I had a similar experience with FreeBSD, when the kernel.ko :stuff went in, and when I accidently trashed /kernel. Backup kernels are easy. Backup dynamic shared libraries are not. apollo:/home/dillon> ls -la /kernel* -r-xr-xr-x 1 root wheel 2264392 Nov 6 10:06 /kernel -r-xr-xr-x 1 root wheel 2127439 Dec 18 1999 /kernel.bak -rwxr-xr-x 1 root wheel 8936898 May 13 13:19 /kernel.debug -rwxr-xr-x 1 root wheel 8501219 Apr 25 2000 /kernel.debug.test4 -rwxr-xr-x 1 root wheel 2378121 May 11 2000 /kernel.diskless -rwxr-xr-x 1 root wheel 1962950 Dec 19 1999 /kernel.diskless2 -rwxr-xr-x 1 root wheel 1875636 Apr 17 1999 /kernel.diskless3 -r-xr-xr-x 1 root wheel 2252413 Nov 6 09:41 /kernel.old -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 8:58:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id A0C5E37B4FE for ; Fri, 10 Nov 2000 08:58:17 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VT2YFD87; Fri, 10 Nov 2000 11:58:19 -0500 Reply-To: Randell Jesup To: Matt Dillon Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> <200011100326.eAA3Q6015450@earth.backplane.com> From: Randell Jesup Date: 10 Nov 2000 12:02:47 -0500 In-Reply-To: Matt Dillon's message of "Thu, 9 Nov 2000 19:26:06 -0800 (PST)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > Linking with a shared library eats memory at run time. It's that simple. > Shared libraries make life easier but they do *NOT* generally reduce > the run time in-core memory footprint of a machine. Dynamic executables > actually increase the number of dirty pages the system has to cope with, > at least for discretely-run programs, and they tend to force the entire > shared library into core. Hmmm. I did some tests of shared-library memory use in FreeBSD and Linux, for a simple libraries with 1 entrypoint and about 2K of code. It appeared that each open library causes 4K usage (according to ps) in FreeBSD, and 8K in Linux. Of course this doesn't tell us how the usage scales with increasing numbers of entrypoints or complexity of code (relocations). If I have saw 20 instances of an executable with 100 shared libraries, or 20 instances of an executable with 5 (much larger) shared libraries, or 20 instances of a very large mostly static executable, what is the relative memory hit? Or swap hit? My test may have been too simple.... How different would the answer be in Linux? (This is for working on figuring out how much of a win it is in Mozilla to combine shared libs, which some people are working on.) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 9:28:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 59D0337B4C5 for ; Fri, 10 Nov 2000 09:28:13 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAAHS9418733; Fri, 10 Nov 2000 09:28:09 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Nov 2000 09:28:09 -0800 (PST) From: Matt Dillon Message-Id: <200011101728.eAAHS9418733@earth.backplane.com> To: Randell Jesup Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> <200011100326.eAA3Q6015450@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : If I have saw 20 instances of an executable with 100 shared :libraries, or 20 instances of an executable with 5 (much larger) shared :libraries, or 20 instances of a very large mostly static executable, :what is the relative memory hit? Or swap hit? My test may have been :too simple.... How different would the answer be in Linux? : : (This is for working on figuring out how much of a win it is in :Mozilla to combine shared libs, which some people are working on.) : :-- :Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) :rjesup@wgate.com However, I would say that for something like Mozilla linking static is going to be a definite win since nearly all the libraries referenced by Mozilla are special purpose - going to be used primarily by Mozilla and not much by anything else. If libX11. There isn't much there that would be shared enough to make it worthwhile vs the memory overhead of the dynamic linking. Having lots of tiny shared libraries is a definite lose, but once a shared library gets over a few hundred K continuing to merge it with other shared libraries isn't going to buy you much vs what you would get with static. One might as well just link static. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 9:34:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 2881437B479 for ; Fri, 10 Nov 2000 09:34:30 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA23844; Fri, 10 Nov 2000 10:30:29 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAkKaatU; Fri Nov 10 10:30:06 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA21973; Fri, 10 Nov 2000 10:33:56 -0700 (MST) From: Terry Lambert Message-Id: <200011101733.KAA21973@usr08.primenet.com> Subject: Re: The shared /bin and /sbin bikeshed To: dillon@earth.backplane.com (Matt Dillon) Date: Fri, 10 Nov 2000 17:33:56 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG In-Reply-To: <200011100326.eAA3Q6015450@earth.backplane.com> from "Matt Dillon" at Nov 09, 2000 07:26:06 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Linking with a shared library eats memory at run time. It's that simple. > Shared libraries make life easier but they do *NOT* generally reduce > the run time in-core memory footprint of a machine. Dynamic executables > actually increase the number of dirty pages the system has to cope with, > at least for discretely-run programs, and they tend to force the entire > shared library into core. > > Its a wash for programs that fork since the library relocations have > already been done by the time you get to the fork, thus all the forked > copies share the original parent's dirty library relocation pages. I've often wondered why no one has bothered to do the necessary work to share relocation pages between instances of the same program, which are not the results of a fork. Actually, I think there was a project at the UofU at one time that supported this, but all the code was in C++, and at the time, the C++ technology on virtual base class construction made it pretty much of a loss. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 9:48:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id B3F7137B479 for ; Fri, 10 Nov 2000 09:48:43 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id KAA14549; Fri, 10 Nov 2000 10:46:48 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAlhaWtC; Fri Nov 10 10:46:39 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA22290; Fri, 10 Nov 2000 10:48:29 -0700 (MST) From: Terry Lambert Message-Id: <200011101748.KAA22290@usr08.primenet.com> Subject: Re: The shared /bin and /sbin bikeshed To: dillon@earth.backplane.com (Matt Dillon) Date: Fri, 10 Nov 2000 17:48:28 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), peter@netplex.com.au (Peter Wemm), imp@village.org (Warner Losh), arch@FreeBSD.ORG In-Reply-To: <200011101654.eAAGsGu18423@earth.backplane.com> from "Matt Dillon" at Nov 10, 2000 08:54:16 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :I had a similar experience with FreeBSD, when the kernel.ko > :stuff went in, and when I accidently trashed /kernel. > > Backup kernels are easy. Backup dynamic shared libraries are not. The "kernel.ko stuff" includes the modified boot loader crap. Backup shared libraries are easy; backup bootblock are not. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 9:57:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 5B54A37B479 for ; Fri, 10 Nov 2000 09:57:20 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAAHvHn19083; Fri, 10 Nov 2000 09:57:17 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Nov 2000 09:57:17 -0800 (PST) From: Matt Dillon Message-Id: <200011101757.eAAHvHn19083@earth.backplane.com> To: Terry Lambert Cc: tlambert@primenet.com (Terry Lambert), peter@netplex.com.au (Peter Wemm), imp@village.org (Warner Losh), arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011101748.KAA22290@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> :I had a similar experience with FreeBSD, when the kernel.ko :> :stuff went in, and when I accidently trashed /kernel. :> :> Backup kernels are easy. Backup dynamic shared libraries are not. : :The "kernel.ko stuff" includes the modified boot loader crap. : :Backup shared libraries are easy; backup bootblock are not. : : : Terry Lambert : terry@lambert.org Ah, ah... right. Whenever I have more then one SCSI disk I always install bootblocks and a root on both. A friend of mine is even more paranoid... he burns a CD. The machine boots up and runs the CD's bootloader which then loads the kernel off the hard drive. This way if the HD is completely fracked it is possible to interrupt the boot sequence at the CD and then boot a CD kernel instead of an HD kernel. That's a little overboard for my tastes, but I can't argue that it doesn't work :-). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 18:58:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 8F4E037B4CF for ; Fri, 10 Nov 2000 18:57:48 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id SAA03567; Fri, 10 Nov 2000 18:57:45 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id eAB2vj034258; Fri, 10 Nov 2000 18:57:45 -0800 (PST) (envelope-from jdp) Date: Fri, 10 Nov 2000 18:57:45 -0800 (PST) Message-Id: <200011110257.eAB2vj034258@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: dillon@earth.backplane.com Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011100326.eAA3Q6015450@earth.backplane.com> References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> <200011100326.eAA3Q6015450@earth.backplane.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200011100326.eAA3Q6015450@earth.backplane.com>, Matt Dillon wrote: > > Linking with a shared library eats memory at run time. It's that simple. > Shared libraries make life easier but they do *NOT* generally reduce > the run time in-core memory footprint of a machine. Dynamic executables > actually increase the number of dirty pages the system has to cope with, > at least for discretely-run programs, and they tend to force the entire > shared library into core. As I'll explain below, I don't share your opinion about this. > Don't forget that even static images can be demand-paged, and for a > static image paging equates to simply throwing the page away since it > is always clean. That is true for the text segment, which is pure, but of course not for the data and bss segments. (I know you understand this, but perhaps not everybody does.) > Demand-paging a dynamic binary requires writing some of those > pages to swap due to the dynamic relocation and each instance of > the binary (when exec'd independantly) have their own private > set of dirty pages to page out. In a shared library, just as in an executable, the text segment is pure. It contains no relocations, and its pages are never dirtied. All of the relocations in a shared library are confined to the data segment. The whole point of the compiler's "-fpic" option is to generate that kind of code, so that the text segment can be pure and 100% shareable. For example, looking at /usr/lib/libc.so from a fairly recent -stable system, we see: austin$ size /usr/lib/libc.so text data bss dec hex filename 508413 15084 78200 601697 92e61 /usr/lib/libc.so The text segment, about 500 KB in size, will be shared among all dynamically linked processes. Only the data and bss segments, about 92 KB, will be unshared. This 92 KB includes all of the run-time relocation. (The main region modified by run-time relocation is the global offset table, and it is compact. In the case of this libc.so, it's a contigous region less than 4 KB in size.) Since most programs only use a small part of libc, they will tend not to touch most pages of that 92 KB. The untouched pages will be shared, since they are mapped copy-on-write. Thus the 92 KB figure exaggerates the amount of unshared memory needed by each instance of libc.so. Whether shared libraries are a win on a given system depends on the job mix. If you are on a system running 30 instances of one program and not much of anything else, shared libraries won't save you any memory. But on a system with a richer job mix, they can save quite a bit. But to keep things in perspective, saving RAM isn't really the main advantage of shared libraries. Their value lies in other areas. They save a lot of disk space; they allow bugs to be fixed in many programs at once via the installation of a single repaired library; and they provide the flexibility of run-time modules ("plug-ins"), which are used by more and more software packages these days. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 19:10:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id 969EA37B4CF for ; Fri, 10 Nov 2000 19:10:10 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAB3Fp909237; Fri, 10 Nov 2000 19:15:51 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011110315.eAB3Fp909237@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Cc: dillon@earth.backplane.com Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Fri, 10 Nov 2000 18:57:45 PST." <200011110257.eAB2vj034258@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Nov 2000 19:15:51 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > But to keep things in perspective, saving RAM isn't really the main > advantage of shared libraries. Their value lies in other areas. They > save a lot of disk space; they allow bugs to be fixed in many programs > at once via the installation of a single repaired library; and they > provide the flexibility of run-time modules ("plug-ins"), which are > used by more and more software packages these days. It would be interesting to know whether the speed overhead (if any) for = PIC code is offset by the improved cache behaviour as well. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 20:49: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 2B7AC37B479 for ; Fri, 10 Nov 2000 20:49:00 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAB4mw122602; Fri, 10 Nov 2000 20:48:58 -0800 (PST) (envelope-from dillon) Date: Fri, 10 Nov 2000 20:48:58 -0800 (PST) From: Matt Dillon Message-Id: <200011110448.eAB4mw122602@earth.backplane.com> To: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011110315.eAB3Fp909237@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This conversation is starting to wander. Please, guys, I am certainly not advocating that we throw away shared libraries! I am fully aware of their advantages. I am simply pointing out that memory utilization is not one of them. The problem with that 92K of data space is that it contains data elements for the entire libc library, not just the pieces you use. The result is that even if you only use a small part of libc, you will still wind up dirtying many of those pages due to the fact that the few elements you do use are spread all over that 92K of data space. Bruce made this clear in his posting, but obviously some people weren't listening. In a static binary only the data elements you reference are linked in, thus packing the data and bss space and reducing the memory footprint. For the vast majority of systems, including mine, shared libraries are preferable for many reasons, but there is an undeniable cost for that convenience. Certain binaries in my Diablo USENET newsfeed code were linked -static precisely because it cut a significant amount of overhead off of separately-exec'd instances. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 21:26:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id A111737B4C5 for ; Fri, 10 Nov 2000 21:26:12 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAB5Vq909851; Fri, 10 Nov 2000 21:31:52 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011110531.eAB5Vq909851@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-reply-to: Your message of "Fri, 10 Nov 2000 20:48:58 PST." <200011110448.eAB4mw122602@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Nov 2000 21:31:52 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The problem with that 92K of data space is that it contains > data elements for the entire libc library, not just the > pieces you use. The result is that even if you only use a > small part of libc, you will still wind up dirtying many of > those pages due to the fact that the few elements you do > use are spread all over that 92K of data space. You might want to check this, actually. How much statically initialised data is there in libc? Not much. 8) You may touch a lot of that 92k, but you're not going to COW very much at all, so you still get the LOR benefits. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 10 23:31:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id CCE1037B479 for ; Fri, 10 Nov 2000 23:31:37 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA78686; Fri, 10 Nov 2000 23:31:27 -0800 (PST) (envelope-from obrien) Date: Fri, 10 Nov 2000 23:31:27 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001110233127.A78632@dragon.nuxi.com> Reply-To: arc@FreeBSD.ORG References: <200011101654.eAAGsGu18423@earth.backplane.com> <200011101748.KAA22290@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011101748.KAA22290@usr08.primenet.com>; from tlambert@primenet.com on Fri, Nov 10, 2000 at 05:48:28PM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 10, 2000 at 05:48:28PM +0000, Terry Lambert wrote: > The "kernel.ko stuff" includes the modified boot loader crap. > Backup shared libraries are easy; backup bootblock are not. Loader != boot blocks. The boot blocks were not changed. It is easy to keep backup copies of the loader. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 2:40:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id B5F1437B479 for ; Sat, 11 Nov 2000 02:40:28 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eABAelE34762 for arch@FreeBSD.ORG; Sat, 11 Nov 2000 11:40:47 +0100 (CET) (envelope-from adrian) Date: Sat, 11 Nov 2000 11:40:47 +0100 From: Adrian Chadd To: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001111114047.A34699@roaming.cacheboy.net> References: <200011101654.eAAGsGu18423@earth.backplane.com> <200011101748.KAA22290@usr08.primenet.com> <20001110233127.A78632@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001110233127.A78632@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Nov 10, 2000 at 11:31:27PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 10, 2000, David O'Brien wrote: > On Fri, Nov 10, 2000 at 05:48:28PM +0000, Terry Lambert wrote: > > The "kernel.ko stuff" includes the modified boot loader crap. > > Backup shared libraries are easy; backup bootblock are not. > > Loader != boot blocks. The boot blocks were not changed. It is easy to > keep backup copies of the loader. Ok. This is getting really really evil. Can we just decide upon a name for the "compile a solaris/linux-like world for me please?" option and commit it? As long as its not default, I'm very happy, and it will be very useful for embedded applications, just like Warner said originally. adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 3:59: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id EA3D737B479 for ; Sat, 11 Nov 2000 03:59:05 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id DAA82596 for arch@freebsd.org; Sat, 11 Nov 2000 03:59:05 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Nov 2000 03:59:05 -0800 From: "David O'Brien" To: arch@freebsd.org Subject: updating rdist Message-ID: <20001111035905.A82574@dragon.nuxi.com> Reply-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have just committed a `44bsd-rdist' port. So the question is, do we totally remove `rdist' from the base system, or update it to rdist 6.1.5? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 7:47: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 5448B37B479 for ; Sat, 11 Nov 2000 07:47:02 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA10734 for ; Sat, 11 Nov 2000 07:46:56 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda10732; Sat Nov 11 07:46:40 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eABFkYk22365 for ; Sat, 11 Nov 2000 07:46:34 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdv22363; Sat Nov 11 07:46:07 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eABFk7X04664 for ; Sat, 11 Nov 2000 07:46:07 -0800 (PST) Message-Id: <200011111546.eABFk7X04664@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdvG4475; Sat Nov 11 07:45:53 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: arch@FreeBSD.ORG Subject: Re: updating rdist In-reply-to: Your message of "Sat, 11 Nov 2000 03:59:05 PST." <20001111035905.A82574@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Nov 2000 07:45:53 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001111035905.A82574@dragon.nuxi.com>, "David O'Brien" writes: > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? The rdist port fails to fetch. In a heterogeneous environment with only 6.1.5 shipped in the base system we can only support rdist with Linux. With 44bsd-rdist we can support rdist with other UNIX systems like Solaris, Tru64-UNIX, etc. I would rather have no rdist and have the option of picking the one I need rather than have the bloat of an rdist that I will not use in a particular situation. (I would rather have an rdist that is compatible with the other 100+ Solaris and Tru64-UNIX systems I manage and the 50+ AIX systems our AIX team manages.) Now that it's in ports I perceive (please correct me if my perception is wrong) that less attention to security and bug fixing might be paid to rdist. Or do we have a commitment that the port will be maintained with as much attention as any software in the base system? Since we now have a 44bsd-rdist port, why don't we maintain it like we did the OpenSSH port: Check it out of the OpenBSD or NetBSD CVS repositories. Then again both rdists could be in contrib (bad for bloat, otherwise less work for those of us installing new systems) and checked out of OpenBSD or NetBSD on a periodic basis. On to another idea and another tangent: Why not leave both rdists in ports and have sysinstall ask the user whether 44bsd-rdist (compatible with most vendors UNIX systems), rdist6 (compatible with Linux), and/or rsync be installed. Enough new ideas for thought. Once again my burning question, will we pay as much attention to the 44bsd-rdist port as we did rdist in the base? And for my preference: If it has to be gone out of the base, then no rdist in the base. Let the user decide which version to install. (If I was managing 100+ Linux systems rather than 100+ Suns & Alphas my preference would obviously be biased differently). Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 7:56:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id E3FCB37B4C5 for ; Sat, 11 Nov 2000 07:56:36 -0800 (PST) Received: from daemon.chronias.ninth-circle.org (root@daemon.ninth-circle.org [195.38.210.81]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id eABFuTW19371; Sat, 11 Nov 2000 16:56:30 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.0/8.11.0) id eABFuQi73701; Sat, 11 Nov 2000 16:56:26 +0100 (CET) (envelope-from asmodai) Date: Sat, 11 Nov 2000 16:56:26 +0100 From: Jeroen Ruigrok/Asmodai To: Warner Losh Cc: Matt Dillon , Peter Wemm , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001111165626.C67634@daemon.ninth-circle.org> References: <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <200011091915.MAA43115@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011091915.MAA43115@harmony.village.org>; from imp@village.org on Thu, Nov 09, 2000 at 12:15:32PM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20001109 20:30], Warner Losh (imp@village.org) wrote: >In the small, embedded world, however, reducing the 4.1M and 12M to >600k and 1200k respectively is a huge win. We at Timing Solutions run >FreeBSD in 16M or 32M or 64M parts where an extra 6M is a huge win. >Especially on the 16M part. The minimal system that I had went from >14.7M to 7.9M which pushed the 16M part from being useless to being >useful (we have about 6M of binaries and sundries that go onto these >systems). Personally I think we are not going the right way with this idea. If I look at the embedded world, the desktop/server world, and the quick system world (picobsd) I see too many differences which can be made to work on each of these platforms. PicoBSD solves this already by using the current source tree and following its own building mechanism. I think it is worthwhile to do something similar like this for our embedded users, since the solutions we need to accomplish this differs vastly for each platform. In the end it allows us to target every special niche in a better way. At least in my opinion. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Love will draw us in, to wipe our Tears away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 9:29:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by hub.freebsd.org (Postfix) with ESMTP id DD03237B479 for ; Sat, 11 Nov 2000 09:29:28 -0800 (PST) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.11.0/8.11.0) id eABHTSr69709 for arch@FreeBSD.ORG; Sat, 11 Nov 2000 12:29:28 -0500 (EST) (envelope-from jwd) Date: Sat, 11 Nov 2000 12:29:28 -0500 From: "John W. De Boskey" To: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001111122928.A69697@bsdwins.com> References: <20001111035905.A82574@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001111035905.A82574@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Nov 11, 2000 at 03:59:05AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please update it. -John ----- David O'Brien's Original Message ----- > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 10:55: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 41E8F37B479; Sat, 11 Nov 2000 10:55:01 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA22752; Sat, 11 Nov 2000 11:54:59 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA04008; Sat, 11 Nov 2000 11:54:58 -0700 (MST) (envelope-from nate) Date: Sat, 11 Nov 2000 11:54:58 -0700 (MST) Message-Id: <200011111854.LAA04008@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: arch@FreeBSD.ORG, dillon@earth.backplane.com Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <200011110315.eAB3Fp909237@mass.osd.bsdi.com> References: <200011110257.eAB2vj034258@vashon.polstra.com> <200011110315.eAB3Fp909237@mass.osd.bsdi.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > But to keep things in perspective, saving RAM isn't really the main > > advantage of shared libraries. Their value lies in other areas. They > > save a lot of disk space; they allow bugs to be fixed in many programs > > at once via the installation of a single repaired library; and they > > provide the flexibility of run-time modules ("plug-ins"), which are > > used by more and more software packages these days. > > It would be interesting to know whether the speed overhead (if any) for > PIC code is offset by the improved cache behaviour as well. Benchmarks done early on tend to say that using PIC code is 10-15% slower than not. For awhile, GCC's internal compiler libraries were compiled shared, but the speedups from compiling them static were significant enough to show static linking is *significantly* faster than shared linking, even if you remove the startup issues. My own benchmarks show (pre-ELF) this as well. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 12: 7: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 4D64037B479; Sat, 11 Nov 2000 12:07:02 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eABK6uE27317; Sat, 11 Nov 2000 12:06:56 -0800 (PST) (envelope-from dillon) Date: Sat, 11 Nov 2000 12:06:56 -0800 (PST) From: Matt Dillon Message-Id: <200011112006.eABK6uE27317@earth.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011110531.eAB5Vq909851@mass.osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> The problem with that 92K of data space is that it contains :> data elements for the entire libc library, not just the :> pieces you use. The result is that even if you only use a :> small part of libc, you will still wind up dirtying many of :> those pages due to the fact that the few elements you do :> use are spread all over that 92K of data space. : :You might want to check this, actually. How much statically initialised :data is there in libc? Not much. 8) You may touch a lot of that 92k, :but you're not going to COW very much at all, so you still get the LOR :benefits. As far as I can tell, Mike, *I* am the *ONLY* one posting actual test results on this topic. Maybe you should run your own tests rather then just assuming I am wrong and telling me to run more. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 14:46:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7D77537B479 for ; Sat, 11 Nov 2000 14:46:22 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA21787; Sat, 11 Nov 2000 14:46:04 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Nov 2000 14:46:04 -0800 From: "David O'Brien" To: Nate Williams Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001111144604.B21664@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200011110257.eAB2vj034258@vashon.polstra.com> <200011110315.eAB3Fp909237@mass.osd.bsdi.com> <200011111854.LAA04008@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011111854.LAA04008@nomad.yogotech.com>; from nate@yogotech.com on Sat, Nov 11, 2000 at 11:54:58AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 11:54:58AM -0700, Nate Williams wrote: > For awhile, GCC's internal compiler libraries were compiled shared, but > the speedups from compiling them static were significant enough to show > static linking is *significantly* faster than shared linking, even if > you remove the startup issues. Hate to say this, but GCC 3.0 will most likely use a shared libgcc. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 14:49: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 6083C37B479; Sat, 11 Nov 2000 14:49:06 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA26371; Sat, 11 Nov 2000 15:49:02 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id PAA08960; Sat, 11 Nov 2000 15:49:01 -0700 (MST) (envelope-from nate) Date: Sat, 11 Nov 2000 15:49:01 -0700 (MST) Message-Id: <200011112249.PAA08960@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: obrien@FreeBSD.ORG Cc: Nate Williams , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <20001111144604.B21664@dragon.nuxi.com> References: <200011110257.eAB2vj034258@vashon.polstra.com> <200011110315.eAB3Fp909237@mass.osd.bsdi.com> <200011111854.LAA04008@nomad.yogotech.com> <20001111144604.B21664@dragon.nuxi.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > For awhile, GCC's internal compiler libraries were compiled shared, but > > the speedups from compiling them static were significant enough to show > > static linking is *significantly* faster than shared linking, even if > > you remove the startup issues. > > Hate to say this, but GCC 3.0 will most likely use a shared libgcc. [ FWIW, it wasn't libgcc that I was speaking of, but the actual libraries for the language. However.... ] Are we *forced* to use it? I would think we have the ability to choose to make it static if we so desire. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 14:49:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id A1B2137B479 for ; Sat, 11 Nov 2000 14:49:18 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA21809; Sat, 11 Nov 2000 14:47:55 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Nov 2000 14:47:55 -0800 From: "David O'Brien" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001111144755.C21664@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20001111035905.A82574@dragon.nuxi.com> <200011111546.eABFk7X04664@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011111546.eABFk7X04664@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Sat, Nov 11, 2000 at 07:45:53AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 07:45:53AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20001111035905.A82574@dragon.nuxi.com>, "David O'Brien" > writes: > > I have just committed a `44bsd-rdist' port. > > So the question is, do we totally remove `rdist' from the base system, > > or update it to rdist 6.1.5? > > The rdist port fails to fetch. Doh! Sorry, I forgot to copy it to the right place to get to the LOCAL_DISTFILES location on ftp.freebsd.org. Fixed w/in an hour now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 14:54: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9931837B4CF for ; Sat, 11 Nov 2000 14:53:58 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA21850; Sat, 11 Nov 2000 14:52:51 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Nov 2000 14:52:51 -0800 From: "David O'Brien" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001111145251.D21664@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20001111035905.A82574@dragon.nuxi.com> <200011111546.eABFk7X04664@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011111546.eABFk7X04664@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Sat, Nov 11, 2000 at 07:45:53AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 07:45:53AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20001111035905.A82574@dragon.nuxi.com>, "David O'Brien" > writes: > > I have just committed a `44bsd-rdist' port. > > So the question is, do we totally remove `rdist' from the base system, > > or update it to rdist 6.1.5? > > Now that it's in ports I perceive (please correct me if my perception > is wrong) that less attention to security and bug fixing might be paid > to rdist. Or do we have a commitment that the port will be maintained > with as much attention as any software in the base system? We put as much attention in fixing the vulnerability in 44bsd-csh as we did contrib/tcsh. Kris (Security Officer) has been spending a *lot* of time on Ports vulnerabilities. His numerous (heck, tons) of FreeBSD Security Advisories shows that. :-) > Since we now have a 44bsd-rdist port, why don't we maintain it like we > did the OpenSSH port: Check it out of the OpenBSD or NetBSD CVS > repositories. I don't see the advantage of doing that. Plus some may want our full CVS repo history for rdist. If you check out the 44bsd-* ports, you'll see that I package the full RCS files up, and any changes to the code has to be done thru RCS. No patches allowed in the 44bsd-* ports. > On to another idea and another tangent: Why not leave both rdists in > ports and have sysinstall ask the user whether 44bsd-rdist (compatible > with most vendors UNIX systems), rdist6 (compatible with Linux), and/or > rsync be installed. It already does, thru the Package installation submenu. ;-) -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 14:54: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4358E37B4D7 for ; Sat, 11 Nov 2000 14:54:02 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA21868; Sat, 11 Nov 2000 14:53:58 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Nov 2000 14:53:58 -0800 From: "David O'Brien" To: Nate Williams Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <20001111145358.E21664@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200011110257.eAB2vj034258@vashon.polstra.com> <200011110315.eAB3Fp909237@mass.osd.bsdi.com> <200011111854.LAA04008@nomad.yogotech.com> <20001111144604.B21664@dragon.nuxi.com> <200011112249.PAA08960@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011112249.PAA08960@nomad.yogotech.com>; from nate@yogotech.com on Sat, Nov 11, 2000 at 03:49:01PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 03:49:01PM -0700, Nate Williams wrote: > > Hate to say this, but GCC 3.0 will most likely use a shared libgcc. > > Are we *forced* to use it? I would think we have the ability to choose > to make it static if we so desire. Building a static binary will of course use libgcc.a. ;-) But you won't have a choice unless I add a FreeBSD-custom option to do so. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 16:52:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id BEB9B37B4CF for ; Sat, 11 Nov 2000 16:52:31 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA11635; Sat, 11 Nov 2000 16:52:31 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11633; Sat Nov 11 16:52:28 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAC0qMX01284; Sat, 11 Nov 2000 16:52:22 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdRI1282; Sat Nov 11 16:52:20 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAC0qJ235536; Sat, 11 Nov 2000 16:52:19 -0800 (PST) Message-Id: <200011120052.eAC0qJ235536@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdE35532; Sat Nov 11 16:52:18 2000 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Mailer: nmh 1.0.4, Exmh 2.1.1 X-Sender: cy To: arch@FreeBSD.ORG Cc: Cy Schubert - ITSD Open Systems Group Subject: Re: updating rdist In-reply-to: Your message of "Sat, 11 Nov 2000 14:52:51 PST." <20001111145251.D21664@dragon.nuxi.com> Date: Sat, 11 Nov 2000 16:52:17 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001111145251.D21664@dragon.nuxi.com>, "David O'Brien" writes: > On Sat, Nov 11, 2000 at 07:45:53AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > In message <20001111035905.A82574@dragon.nuxi.com>, "David O'Brien" > > writes: > > > I have just committed a `44bsd-rdist' port. > > > So the question is, do we totally remove `rdist' from the base system, > > > or update it to rdist 6.1.5? > > On to another idea and another tangent: Why not leave both rdists in > > ports and have sysinstall ask the user whether 44bsd-rdist (compatible > > with most vendors UNIX systems), rdist6 (compatible with Linux), and/or > > rsync be installed. > > It already does, thru the Package installation submenu. ;-) One last request, if you missed it, please don't put it in base. Let the user decide whether to install 44bsd-rdist, rdist6, both, or neither. As they don't support the same protocol, this may cause confusion for those who think rdist6 may interoperate with Solaris or other vendor's rdist, while rdist6 will interoperate with RedHat Linux rdist. Also, documentation clarifying interoperability issues between the two major versions of rdist s/b put in the handbook and/or the description files of each port. (We could even put a plug in for rsync). Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 18:13: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 5820E37B479; Sat, 11 Nov 2000 18:13:01 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id eAC2CtH49755; Sat, 11 Nov 2000 21:12:55 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id eAC2Cs476005; Sat, 11 Nov 2000 21:12:54 -0500 (EST) (envelope-from bsd) Date: Sat, 11 Nov 2000 21:12:54 -0500 From: Brian Dean To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001111211254.B75129@vger.bsdhome.com> References: <20001111035905.A82574@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001111035905.A82574@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Nov 11, 2000 at 03:59:05AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? My strong preference is to have an rdist in base. Please update rather than remove. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 18:48: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 57A1137B479; Sat, 11 Nov 2000 18:48:01 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id SAA11820; Sat, 11 Nov 2000 18:47:54 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11818; Sat Nov 11 18:47:38 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAC2lXg01562; Sat, 11 Nov 2000 18:47:33 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdTe1560; Sat Nov 11 18:46:55 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAC2ksC39398; Sat, 11 Nov 2000 18:46:54 -0800 (PST) Message-Id: <200011120246.eAC2ksC39398@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdo39297; Sat Nov 11 18:46:02 2000 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Mailer: nmh 1.0.4, Exmh 2.1.1 X-Sender: cy To: Brian Dean Cc: "David O'Brien" , arch@FreeBSD.ORG Subject: Re: updating rdist In-reply-to: Your message of "Sat, 11 Nov 2000 21:12:54 EST." <20001111211254.B75129@vger.bsdhome.com> Date: Sat, 11 Nov 2000 18:46:01 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001111211254.B75129@vger.bsdhome.com>, Brian Dean writes: > On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > > > I have just committed a `44bsd-rdist' port. > > So the question is, do we totally remove `rdist' from the base system, > > or update it to rdist 6.1.5? > > My strong preference is to have an rdist in base. Please update > rather than remove. However, it won't be compatible with any vendors rdist and will only be useful in FreeBSD/Linux-only environments unless rdist6 has been installed on any vendors (Solaris, Tru64-UNIX, AIX, HP/UX, DG-UX, ...) systems you may manage. If we're not interoperable with other UNIXen, why even have it in base? If you manage a mix of FreeBSD/Linux systems only I can see having it in base. If you manage a heterogeneous environment with legacy applications that use rdist across platforms, like I do, it's just bloat that can be installed if required from ports. If you manage a new site without any ties to the past, skip rdist entirely and use rsync. If you have to interoperate with Solaris, AIX, Tru64-UNIX, HP/UX, DG-UX, and SVR4.2: Use 44bsd-rdist. If you have to interoperate with Linux: Use rdist6. If you want to use something truly modern: Use rsync. If you are going to go to all the trouble of installing rdist6 on vendor systems, e.g. Solaris, etc., in order to interoperate with the Linux and proposed FreeBSD, why not install rsync instead. It's eaiser to use and doesn't require a distfile. That's why I think rdist is bloat. Hence I don't think there should be any preference given to one software/file distribution package over another. They all attempt to do the same thing using different protocols. Let the user decide what they need for their environment. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 21: 3:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D3E5037B479 for ; Sat, 11 Nov 2000 21:03:09 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id AAA06743 for ; Sun, 12 Nov 2000 00:03:09 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id eAC539w29530; Sun, 12 Nov 2000 00:03:09 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 12 Nov 2000 00:03:09 -0500 (EST) To: arch@freebsd.org Reply-To: arch@freebsd.org Subject: Re: updating rdist In-Reply-To: <20001111035905.A82574@dragon.nuxi.com> References: <20001111035905.A82574@dragon.nuxi.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14862.9298.59870.209107@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien writes: > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? I'd vote for removal. Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 21:16:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id E2DCA37B479 for ; Sat, 11 Nov 2000 21:16:51 -0800 (PST) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id AAA19551 for ; Sun, 12 Nov 2000 00:16:50 -0500 (EST) Date: Sun, 12 Nov 2000 00:16:50 -0500 (EST) From: To: arch@FreeBSD.ORG Subject: Re: updating rdist In-Reply-To: <14862.9298.59870.209107@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I second removing it and making it a port. The more things that just add bloat that get out of the base and into port's makes me happy happy happy. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 11 22:54:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7C9EE37B479 for ; Sat, 11 Nov 2000 22:54:38 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAC6sbC01203 for ; Sat, 11 Nov 2000 23:54:37 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA58578 for ; Sat, 11 Nov 2000 23:54:37 -0700 (MST) Message-Id: <200011120654.XAA58578@harmony.village.org> Subject: Re: The shared /bin and /sbin bikeshed To: arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 10 Nov 2000 02:55:22 PST." <20001110025522.B15361@citusc17.usc.edu> References: <20001110025522.B15361@citusc17.usc.edu> <200011100938.CAA48105@harmony.village.org> <200011100959.eAA9xJ905757@mass.osd.bsdi.com> Date: Sat, 11 Nov 2000 23:54:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce has pointed out that my patch is a poor man's version of NOSHARED=no, which is closer to what I want anyway. So I'll just use that instead. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message