From owner-freebsd-hackers  Tue Jun 20 19:50:57 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id TAA27516
          for hackers-outgoing; Tue, 20 Jun 1995 19:50:57 -0700
Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA27510
          for <hackers@freebsd.org>; Tue, 20 Jun 1995 19:50:51 -0700
Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au 
          id <20935-0@bunyip.cc.uq.oz.au>; Wed, 21 Jun 1995 12:49:49 +1000
Received: from netfl15a.devetir.qld.gov.au 
          by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP 
          id LAA09659 for <hackers@freebsd.org>;
          Wed, 21 Jun 1995 11:04:13 +1000
Received: by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id BAA14892;
          Wed, 21 Jun 1995 01:00:47 GMT
Date: Wed, 21 Jun 1995 01:00:47 GMT
From: Stephen Hocking <sysseh@devetir.qld.gov.au>
Message-Id: <199506210100.BAA14892@netfl15a.devetir.qld.gov.au>
To: hackers@freebsd.org
Subject: Re: freebsd and memory
Sender: hackers-owner@freebsd.org
Precedence: bulk


>>* is FreeBSD using demand paging for it's shared libs - i don't think (i can
>
>   Yes, FreeBSD uses demand paging for all mapped file operations. This
>includes shared libraries as well as regular binaries. The main reason that
>Linux uses less memory is that they go to great lengths to order the routines
>in the shared libraries to reduce the sparseness of accesses for typical
>programs. This results in fewer page faults and less memory consumption when
>a small set of of programs are involved.
>   Another difference is the Linux filesystem. It plays much more "fast and
>loose" with the updates of metadata which makes it much faster at file
>creations and deletions, but also makes it more suseptable to severe filesystem
>corruption if the system should crash.
>
>-DG

	This is one of my pet subjects. I've been collecting large numbers of
papers upon the arcane art of building programs to minimise page faults. One
bloke did a Q&D version of a program on a Unix box that looked at profiling
data & just ordered the modules at link time according to that.
Theoretically you should go for something that records page references vs
time, but this method gave most of the gains using existing tools. The paper
in question was titled "A Study of Program Restructuring in a Virtual Memory
System", by Jerry Breecher. I only have a photocopy of the article, not the
entire journal, so I can't tell you what journal it's from, but I suspect it
was one of the IEEE publications. Something to do this would be hackable
from shell, gprof, awk, nm & ar. It would give us the benefits not only of
reduced paging but probably also improved cache hit ratios. Whilst profiling
only works on statically linked objects, we could pull out the routines that
would be in the shared library and order the shared library appropriately.
Maybe after I've done the stallion driver, ported the GPM modula 2 compiler,
done the 16bit colour for Sierra RAMDACs.

	Domenico Ferrari of UCB has also put out a few good papers on this
subject. Now if only we could persuade the GNU people to write programs that
did not splatter their data all over a large amount of memory.

	Stephen