From owner-freebsd-hackers Sat Apr 1 07:54:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA15140 for hackers-outgoing; Sat, 1 Apr 1995 07:54:17 -0800 Received: from vinkku.hut.fi (vode@vinkku.hut.fi [130.233.245.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA15134 for ; Sat, 1 Apr 1995 07:54:14 -0800 Received: (from vode@localhost) by vinkku.hut.fi (8.6.11/8.6.7) id SAA10589; Sat, 1 Apr 1995 18:54:03 +0300 Date: Sat, 1 Apr 1995 18:54:03 +0300 From: Kai Vorma Message-Id: <199504011554.SAA10589@vinkku.hut.fi> To: hackers@FreeBSD.org Subject: Two proposals Reply-to: Kai.Vorma@hut.fi Sender: hackers-owner@FreeBSD.org Precedence: bulk 1) /alt-hierarchy I installed today the new rc files and sysconfig. I think /etc/sysconfig is great idea (I actually created a bit similar system about two months ago for our SP2 cluster. It uses perl and is more powerful than sysconfig but a bit more complicated and designed for clusters. It also has an ability to generate arbitary configuration files using prototype file and system database). However one must still edit other files like /etc/ttys and so on. When updating your system it is always hard to remember which files are modified and must be preserved before update. I have solved this problem by creating an alternate root directory /alt. Now if I must edit some file /etc/foo/bar I first move it to /alt/etc/foo/bar and then symlink it to /etc/foo/bar. In that way all modified files are nicely kept in one place. For example my machine has : /etc/aliases -> ../alt/etc/aliases /etc/fstab -> ../alt/etc/fstab : /bin/zsh -> ../alt/bin/zsh : [ it is essential to use relative symlinks in some situations on some machines (try /etc/filesystems -> /alt/etc/filesystems on AIX :-) and it is best no to move /etc/passwd & co. because vipw may destroy links. ] The same goes with /usr. I have /usr/alt although it almost empty containing only my kernel and XFree86 configuration files. In work I use a bit more complicated system that works better when you have a bunch of mostly similary configured machines and distribute (rdist, sup) configuration files from some server. It uses /alt/sysdep (shared files), /alt/hostdep (host specific files) and /alt/vendor for saving the original files. Then I have a perl-script that makes links by giving priority those in /alt/hostdep hierarchy. Simple /alt is enough for most situations, though. 2) Malloc I installed few days ago Netscape-1.1b. It is a nice program, but quite memory hungry and makes your X-server fat, too. I relinked my X-server (XFree86-3.1.1) with gnumalloc and its memory usage (VSZ) dropped from 7MB to 4MB! It seems, that the standard FreeBSD malloc wastes memory quite liberally. The VM-system probably can reclaim some (most?) of those wasted pages, but not all. From malloc.c: * This is a very fast storage allocator. It allocates blocks of a small * number of different sizes, and keeps free lists of each size. Blocks that * don't exactly fit are passed up to the next larger size. In this * implementation, the available sizes are 2^n-4 (or 2^n-10) bytes long. * This is designed for use in a virtual memory environment. So if you malloc(1024) the overhead is another 1024 bytes.. I think it is quite common to malloc 2^n or 2^n-1 bytes of memory (see almost any WHATEVER_MAX in ) so this is really stupid. It has also some other shortcomings like not being able to coalesc returned memory. I think we should search for better mallocs. I found 3 promising packages: o GnuMalloc o CSRI malloc V1.17 (alpha?) o Malloc-2.5.3b by Doug Lea We already have (an old version of) gnumalloc in separate library but I would like to see something integrated into libc. I tried Malloc-2.5.3b for a few days but it broke sed so I had to give up. I think FreeBSD-1.1.5 had some older version of CSRI malloc as libmalloc. The CSRI malloc seems to be very space efficient but perhaps a bit slow. I haven't (yet) tried to replace libc malloc with CSRI malloc. ..vode