Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!metro!metro!asstdc.scgt.oz.au!nsw.news.telstra.net!act.news.telstra.net!imci3!imci2!news.internetMCI.com!newsfeed.internetmci.com!in2.uu.net!news.thepoint.net!news1!not-for-mail
From: root@dyson.iquest.net (John S. Dyson)
Subject: Re: Linux vs. FreeBSD ...
X-Nntp-Posting-Host: dyson.iquest.net
Message-ID: <4oadap$6pb@dyson.iquest.net>
Sender: news@iquest.net (News Admin)
Organization: John S. Dyson's home machine
References: <3188C1E2.45AE@onramp.net> <4o3ftc$4rc@zot.io.org> <31A5A8F6.15FB7483@zeus.co.uk> <31A5D0A8.59E2B600@zeus.co.uk>
Date: Sun, 26 May 1996 20:01:29 GMT
Lines: 95
In article <31A5D0A8.59E2B600@zeus.co.uk>,
Damian Reeves <damian@zeus.co.uk> wrote:
>
>"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."
>
Not true, a couple of FreeBSD people understand the VM system as well
in many ways as the original developers. In fact, we have improved
on it. My assertion is also true regarding the low-level CPU code, networking
code, etc. FreeBSD is an evolving entity. There is very little
"religion" holding FreeBSD back. Also, there is significant contact
between the FreeBSD developers and the "originals", because they have
alot of background and expertise (The FreeBSD developers don't know
"everything".) We also have respect for them and their opinion -- and
welcome their help and participation.
>
>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.
>
Given the FreeBSD 2.1 series and before, the above statement is true, only if
you change the word "memory" to "virtual memory." In -current that statement
is not true.
>
>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.
>
Not true. We have over-commit also (call that a bug OR feature.) FreeBSD
is very aggressive about pushing unused pages out to disk, and it's allocation
algorithm can be a bit sparse. I would want to have unused pages
pushed to disk rather than residing lazily in memory.
>
>Ah, so this is the kind of in-depth analysis and discussion I can
>expect from FreeBSD developers is it.
>
I am one of the serious FreeBSD developers, please don't lump all people
into the same category.
>
>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.
>
Hmmm... It isn't memory until you use it. On FreeBSD, pages are NOT
created until used (even in .data, but without looking more carefully
at the source code, those decls look like .bss.) The only cost is that of page
table space (IFF the space is used or preloaded, and there is virtual space
occupied after the addresses used by space and on the same page table page.)
Except regarding the address space sparseness issue, the memory above isn't
alot different than malloc'ed space, except it is faster to use the
first time (because the address maps (struct vm_map, and struct vm_map_entries)
don't have to be manipulated by sbrk and friends.)
>
>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
^^^^ It isn't
"data segment", but it is in the sbrk area which, many times, depending
on circumstances is an extension of the .bss.
>back to the OS?
>
Again, that has been fixed/changed for months in -current. BTW, we have
done significant, detailed comparisons, and have decided NOT to use the
malloc used by Linux, for performance and other reasons.
>
>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.
>
Interesting, since the 4.3 book doesn't really describe what we have. The
4.4 book is more up-to-date, but FreeBSD has made significant advances
since then. The 4.4 book is a good starting point and should be required
reading for any kernel hacker (IMO.) That isn't to say that the 4.3 book
isn't interesting reading though.
John
dyson@freebsd.org