Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!news.cps.udayton.edu!news.engr.udayton.edu!blackbird.afit.af.mil!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!bofh.dot!warwick!lyra.csx.cam.ac.uk!news
From: Damian Reeves <damian@zeus.co.uk>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs. FreeBSD ... (FreeBSD extremely mem/swap hungry)
Date: Fri, 24 May 1996 16:07:20 +0100
Organization: Zeus Technology Ltd.
Lines: 155
Message-ID: <31A5D0A8.59E2B600@zeus.co.uk>
References: <3188C1E2.45AE@onramp.net> <4n0dhd$cff@agate.berkeley.edu> <3194622D.41C67EA6@Ami-chan.res.cmu.edu> <31A52667.794BDF32@zeus.co.uk> <4o3ftc$4rc@zot.io.org> <31A5A8F6.15FB7483@zeus.co.uk>
NNTP-Posting-Host: jobbie.chu.cam.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.1.0-RELEASE i386)
This was a mail response sent to me directly, but I thought I'd post it
here as well for further discussion.
---
>>>>> "Victor" == Victor Langeveld <Victor.Langeveld@mbfys.kun.nl> writes:
Victor> In comp.unix.bsd.freebsd.misc you write:
>> Yun-Ching (Allen) Lee wrote:
>>> Performance: Since I only have a 486DX 33 with 20 MB of RAM,
>>> I want > [...]
>> Your damm right they do! I think the FreeBSD developer's are
>> subsidised by ram and harddrive manufactures. [...]
Victor> Sorry to say that your 'report' about your FreeBSD
Victor> findings are complete nonsense. Try a FreeBSD machine
Victor> with heavy netload, and try to use a Linux machine to do
Victor> the same. Linux is a nice toy for people to play with at
Victor> home, nothing more. It's not mature (yet).
Unfortunately, is it you that are mistaken. I have not mentioned
network performance, or performance at heavy load, why then are you
trying to bring them into this discussion on VM usage?
>> time the Xserver and xterms have started, 50MB of swap is in
>> use!!!
Victor> So? Do you know what this means?
Indeed, I know exactly what this means.
>> I had to increase the swap space upto 250Mb just so we could
>> actually compile our server code. At the moment, the machine
>> is sitting there
Victor> I simply don't beleive this. True, 16Mb ram and 32Mb swap
Victor> makes 48Mb memory on Linux, while it makes only 32Mb of
Victor> memory with FreeBSD, but there are very sound reasons for
Victor> this behaviour. I'm not going to discuss details here,
Victor> there are some books which can explain this much better
Victor> than I. FreeBSD profits from more than 10 years of
Victor> Berkeley experience. Linux is built from the ground up.
"Our program is so old, no one who wrote the internals is even alive
anymore, we couldn't possibly alter them, let alone describe the
design decisions that contributed to this large chunk of code we
don't understand."
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.
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. Under
Linux, no such pre-reservation occurs, malloc's() cannot fail. The
memory is allocated on demand as the pages that have been 'reserved'
are dirtied by the process. For example, under Linux on a 8mb
machine, I can malloc() a sparse array of 200mb which will succeed,
write to the first and last bytes of this data, which will increase
the process SIZE by only 2 4k pages. On the same machine under BSD,
this is impossible (unless you have > 200mb of swap space).
>> response to my keystrokes. This paging also seems to lock the
>> entire machine at lot more than under linux (EIDE drive
>> subsystem).
Victor> Linux might feel more snappy than FreeBSD, agreed. But
Victor> watch what happens with a serious load...
I am not discussing load here, that is irrelevant. Load and paging
are two totally different things.
>> 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. The fixed alloca() and strength reduction
optimisations are quite necessary for proper execution of some
programs. GCC 2.7.2 does an awful lot more optimisations than 2.6.3,
and timings noted were for release builds involving maximum
optimisations.
>> In summary then, its fast, but resource hungry in the extreme.
>> I guess
Victor> Nonsense.
Ah, so this is the kind of in-depth analysis and discussion I can
expect from FreeBSD developers is it.
>> the pages. I'd say there is probably a memory leak in the
>> system libc
Victor> You are out of your mind.
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?
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
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 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.
>> as well. One more thing, using tmpfs really eats VM, and I'm
>> not sure if it actually returns it to the system on deleting
>> files in there.
Victor> You are kidding?
Do you understand that when a user-level process malloc()s memory from
the kernel, a subsequent free() does not return the VM back for use by
other processes? Do you know if the mount_mfs() process invokes the
kernel sbrk() call to manually return unused pages in its data segment
back to the OS?
Victor> These are all statements without a proper base. You'd
Victor> better stop making a fool of yourself. And stay with
Victor> Linux if you like it that much.
No, let me see who is a fool. I suggest you go out and read the
excellent "The Design and Implementation of the 4.3BSD UNIX Operating
System", then go and read some kernel source, then read libc, then
actually play with 'ps' to visualise your new found knowledge.
Damian
--
Damian Reeves, <damian@zeus.co.uk> Zeus Technology Ltd.
Download the world's fastest webserver today! http://www.zeus.co.uk