*BSD News Article 69430


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!newsreader.sprintlink.net!helena.MT.net!nate
From: nate@trout.sri.MT.net (Nate Williams)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs. FreeBSD ... (FreeBSD extremely mem/swap hungry)
Date: 26 May 1996 01:26:24 GMT
Organization: SRI Intl. - Montana Operations
Lines: 164
Message-ID: <4o8c01$pbi@helena.MT.net>
References: <3188C1E2.45AE@onramp.net> <4o3ftc$4rc@zot.io.org> <31A5A8F6.15FB7483@zeus.co.uk> <31A5D0A8.59E2B600@zeus.co.uk>
Reply-To: "Nate Williams" <nate@sneezy.sri.com>
NNTP-Posting-Host: trout.sri.mt.net

[ Emailed as well ]

In article <31A5D0A8.59E2B600@zeus.co.uk>,
Damian Reeves  <damian@zeus.co.uk> wrote:
>You obviously don't understand the workings of the BSD kernel memory
>manager, and how it compares with that under Linux.
>
>Under BSD, memory is allocated on a binary buddy system causing all
>blocks to be allocated of sizes that are a power of 2.  This wastes a
>lot of memory (ask for 2mb+1byte and the kernel will reserve 4mb of
>memory for you).  Linux on the otherhand supports the allocation of
>arbitary sized blocks.

As SEF points out in a companion article, this is a library issue.  If
you don't like using the standard malloc in FreeBSD 2.1, use GNU-malloc
which is the exact same as the one in Linux.  Or, you can upgrade to
-current (or just grab the library file) and get a newer/better/faster
version which is faster than the version in Linux.  (

>Secondly, and the most significant difference, is the different
>semantics of the malloc() call.  Under BSD, a process performing a
>malloc() of 100k will actually reserve 100k of memory from the VM
>system, or return failure if that memory cannot be allocated.

You haven't used a recent BSD system lately have you?

Script started on Sat May 25 19:17:45 1996
moth:~ % uname -a
FreeBSD moth.sri.MT.net 2.1-STABLE FreeBSD 2.1-STABLE #3: Mon Jan  8 17:47:44 MST 1996     root@moth.sri.MT.net:/usr/src/sys/compile/SNDMOTH  i386
moth:~ % cat > mem.c
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define MAXMEM  64 * 1024 * 1024

int
main()
{
   char *mem;

   mem = (char *)malloc(MAXMEM);
   if ( mem == NULL ) {
      fprintf(stderr, "Whoops, can't malloc that much\n");
      exit ( -1 );
   }
   mem[0] = 1;
   mem[MAXMEM -1 ] = 1;
   sleep(2000);          /* Leave it in memory long enough to see it */
 
   return 1;
}
^D
moth:~ % gcc -Wall mem.c
moth:~ % a.out
Whoops, can't malloc that much
moth:~ % unlimit
moth:~ % a.out
^Z
Suspended
moth:~ % bg
[1]    a.out &
moth:~ % ps guaxww | fgrep a.out
nate      3326  0.0  1.8   256  536  p2  S+    7:18PM    0:00.02 fgrep a.out
nate      3307  0.0  1.6 65676  488  p2- I     7:15PM    0:00.02 a.out
nate      3324  0.0  1.6 65676  488  p2  S     7:18PM    0:00.02 a.out
moth:~ % swapinfo
Device      1K-blocks     Used    Avail Capacity  Type
/dev/sd0s2b     65536        0    65472     0%    Interleaved
/dev/wd0s3b     49152        0    49088     0%    Interleaved
Total          114560        0   114560     0%
moth:~ % exit

Script done on Sat May 25 19:18:13 1996

And that's using an old version of FreeBSD.   Obviously I didn't use up
more space than that.  I'll admit that I purposefully malloc'd space on
a nice boundary, but until I touch the page it won't matter anyway.

>    >> anyone have a gcc/g++ 2.7.2 working properly yet or do FreeBSD
>    >> people not care?)
>    Victor> Do you know the difference between 2.6.3 and 2.7.2?  Or
>    Victor> are you someone who can't wait to install the latest
>    Victor> kernel and libc?
>
>Indeed I do.  If have ever got past writing hello world in C++ you
>would understand that polymorphic templates and exception support was
>actually quite useful.

Not to me.

> The fixed alloca() and strength reduction
>optimisations are quite necessary for proper execution of some
>programs.

Alloca() works in gcc2.6.3, and the strength reduction patch exists in
FreeBSD's version of gcc2.6.3.

> GCC 2.7.2 does an awful lot more optimisations than 2.6.3,
>and timings noted were for release builds involving maximum
>optimisations.

It also generates bogus code in *many* cases.  In at least as many cases
(if not more) than gcc2.6.3.  However, with gcc.2.6.3 we (FreeBSD) know
about most of the bugs and as such have work-around for them.

Rumor has it gcc 2.7.3 is going to be RSN, so maybe that'll mean FreeBSD will
upgrade if it's 'significantly' more stable than 2.6.3/2.7.2.

>and more, indeed I'm sure I'm completely mad.  Have you actually
>watched the RSS of the Xfree 3.1.2 Server increase as you repeatedly
>load and quit Netscape?

It hasn't on my system, and I run netscape often on a lowly 16MB 486/66.
 Until last week I was up 104 days, and I was using 21MB of swap, and I
consistantly use XEmacs and Netscape, both programs which have a huge
memory footprint.

>Have you ever wondered why the code to display a little mail box icon
>and stat a file every few minutes (read xbiff), requires 1.3Mb of
>memory??
>
>I'll even give you my ps listing for it:
>
>  PID STAT  TIME     SL  RE PAGEIN   VSZ  RSS   LIM TSIZ %CPU %MEM
>COMMAND
> 1200 S    0:00.34  11 1122     10   224 1364     -   12  0.0  4.4 xbiff

Is that for Linux?  I'm not familiar wit the output.  Here's mine and
it's been running for 12 days straight?

USER       PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED       TIME COMMAND
nate      1012  0.0  0.9   208  128  ??  S    13May96    0:36.76 /usr/X11R6/bin/xbiff -geometry 50x50+0+92 -bg lightslategrey -file /home/nate/Mail/spool/mbox

>Have you actually looked through libc code to tell me there are no
>memory leaks?  Have you constructed a proof in your favourite temporal
>logic?

Have yo done this with Linux?

>Have you seen the amount of static data that libc uses?  Do you
>understand that this means that every application which is linked with
>libc (read a lot) has to allocate this as part of their data segment.
>For example, in crypt() alone, there's a nice line of:
>
>long32 ufc_sb0[8192], ufc_sb1[8192], ufc_sb2[8192], ufc_sb3[8192];
>
>That's 128k of memory in cause you are numerically challenged as well.

Umm, what in the *heck* are you running for an OS?  It certainly isn't
any recent vintage of FreeBSD, which happens to be the OS you are
slamming here.  The rest of the article is deleted since very little of
it is relevant to FreeBSD.

You obviously don't have any idea what you are talking about given that
you are using examples that are from a completely different OS.


Nate
-- 
nate@sri.com           | Research Engineer, SRI Intl. - Montana Operations
nate@trout.mt.sri.com  | Loving life in God's country, the great state of
work #: (406) 449-7662 | Montana.
home #: (406) 443-7063 | A fly pole and a 4x4 Chevy truck = Heaven on Earth