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!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!in2.uu.net!cygnus.com!kithrup.com!sef From: sef@kithrup.com (Sean Eric Fagan) Subject: Re: Linux vs. FreeBSD ... (FreeBSD extremely mem/swap hungry) Organization: Kithrup Enterprises, Ltd. Message-ID: <DrxB6M.Iyn@kithrup.com> References: <3188C1E2.45AE@onramp.net> <4o3ftc$4rc@zot.io.org> <31A5A8F6.15FB7483@zeus.co.uk> <31A5D0A8.59E2B600@zeus.co.uk> Date: Fri, 24 May 1996 18:54:22 GMT Lines: 137 In article <31A5D0A8.59E2B600@zeus.co.uk>, Damian Reeves <damian@zeus.co.uk> wrote: >This was a mail response sent to me directly, but I thought I'd post it >here as well for further discussion. If it had been my message you had posted, I would have cancelled your article. (Assuming you didn't have permission to post private email, of course.) >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? Because an operating system is more than just one facet. An operating system, in fact, is more than just a kernel. >"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." Uh... actually, everyone who wrote the internals of BSD is still quite alive. In fact, I went and got a copy of the 4.4BSD book on Tuesday, and got it signed by one of the authors. I'll try to get the others as time goes by. Kirk McKusick periodically offers a kernel walkthrough class for BSD; I'm told that, right now, he's using FreeBSD. (When I took the class, they were using BSDi's BSD/386.) I promise you, he does understand the internals quite well, and is quite willing to discuss the design decisions that caused the algorithms to be chosen. >You obviously don't understand the workings of the BSD kernel memory >manager, and how it compares with that under Linux. I do not know the Linux code, I admit that. I do understand the BSD code fairly well (Net/2, 4.4Lite, FreeBSD) fairly well. >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. Uh... that is a library issue, not a kernel issue. Specifically, malloc(), which is not a system call. And FreeBSD has a couple of different mallocs it comes with; they behave differently (space vs. time tradeoffs are common). You can roll your own malloc, of course, and several packages provide their own. The kernel-level memory allocation system calls are brk() (sbrk() on some systems is an actual system call; on others, it's a wrapper for the brk() system call) and mmap(). >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. Historically, BSD has backed memory with swap space. FreeBSD, however, does not -- it uses the same method you ascribe to Linux. It is called "lazy allocation." In fact, Net/2 used this same method -- it was a hold-over from the Mach VM code that Net/2 and later used. (I believe that Lite or Lite2 tries to keep track of how much swap space is used, so won't allow it. FreeBSD, however, does allow it.) >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). And then, when you modify a byte somewhere in the middle, either your program, or some other randomly-chosen process, will be killed because you've run out of physical and swap memory. That is why some people do not like lazy allocation. I, personally, happen to prefer it -- I think address spaces tend to be sparse these days. Some systems, such as AIX, allow the administrator to choose, and that, of course, is the best way to handle it. >I am not discussing load here, that is irrelevant. Load and paging >are two totally different things. Not completely. (I could back it up, but why bother? You'd just claim it was irrelevant.) >Ah, so this is the kind of in-depth analysis and discussion I can >expect from FreeBSD developers is it. Pot. Kettle. Black. (Too subtle for you?) >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? Actually, some kernels do. The Net/2 kernel didn't; I don't know if current FreeBSD actually releases the pages that after a brk() moves things around. You can get rid of pages, however, using munmap(). >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? Well, actually, that's not how MFS works. It allocates a fixed size of memory (based on command line arguments, or the default if none are given), "formats" that memory so that it looks like a UFS filesystem, and then goes into kernel mode and never comes back until the filesystem is unmounted. Since the VM allocation (in FreeBSD) is lazy, neither phyiscal or swap memory are used until the memory is actually touched (read or written). When a file is removed, however, it doesn't get "returned to the system." It will just sit there eating up space; however, the filesystem will be able to reuse it, hopefully. >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 I have read that book. I've read the 4.4 version of the book too (and, in fact, if you look on page xii, at the beginning of teh fifth line, you may see some proof that some folks *do* believe that I know what I'm talking about). I've read, and modified, kernel sources, and I still have some code in libc. You, on the other hand, appear to be trolling for flames in a Linux vs. BSD war. Why, I don't know; I don't see any reason for baseless arguments -- and your ignorance about BSD internals, let alone FreeBSD internals, make most of your arguments baseless. Normally, I wouldn't've bothered posting, but, as with the last time I posted in this newsgroup, the amount of disinformation in your post was just too much to let pass by. Someone might accidently believe you.