From owner-freebsd-questions Fri Aug 4 06:29:27 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA11079 for questions-outgoing; Fri, 4 Aug 1995 06:29:27 -0700 Received: (from dyson@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA11070 ; Fri, 4 Aug 1995 06:29:26 -0700 From: John Dyson Message-Id: <199508041329.GAA11070@freefall.cdrom.com> Subject: Re: 2.0.5 Eager to go into swap To: jiho@sierra.net Date: Fri, 4 Aug 1995 06:29:26 -0700 (PDT) Cc: davidg@Root.COM, freebsd-questions@freefall.cdrom.com In-Reply-To: <199508031855.AA08146@diamond.sierra.net> from "Jim Howard" at Aug 3, 95 10:59:12 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2415 Sender: questions-owner@FreeBSD.org Precedence: bulk > > Wait a minute, in FreeBSD shared libraries are MAPPED in by > ld.so using the mmap() function, using copy-on-write with text > (code) pages marked read-only. That means shared libraries > are used in as page-efficient a manner as is humanly possible, > with virtually no human intervention. Physical RAM pages > (4 KB chunks) are occupied as they are accessed, on the fly.... > or at least, that's how it's supposed to work. Since mmap() On FreeBSD, if the pages are already in memory, the pages are prefaulted into the processes address space. This elimnates lots of pagefaults at the very small cost of slightly longer (in the scheme of things) mmap times. > > So what's going on? I have 8 MB of RAM with a 16 MB swap > partition, and my machine behaves the same as people > describe with 32 MB! When running X, my machine behaves > as if the FreeBSD virtual memory subsystem were using the > amount of virtual memory given to processes, rather than the > number of pages actually occupied, as the basis for deciding > whether or not to use swap. Which is crazy, because the > point of swapping is to free up occupied pages when none > are unoccupied. > > Right? Am I missing something here? > FreeBSD does page when it is out of physical memory (or nearly so). It is about as efficient as it can be (throwing a bit more CPU at the problem). The actual amount of CPU used in the pageout daemon is less than earlier versions of *BSD because FreeBSD is more productive when in the pageout daemon and wakes it up less gratuitously. I will be including some improvements into the code for 2.2 that will improve it further. I think that you are seeing good performance because the page-in heuristics do apparently work well with modern drives. Many of the concepts in the pageout daemon are the work of DG and me, and it suprised me the performance differenc when using a more modern drive. (Actually, I was suprised at the LOW performance of an older drive.) FreeBSD is also very good a sharing pages. It is almost excessively good at sharing pages across parent/child inheritance (too good for its own health) causing something called the "collapse problem", which we fixed fully (finally) in 2.0.5. It would be interesting for you to periodically run pstat -s to see how much swap space is being occupied. I'll bet you that you have been paging and don't know it :-). John dyson@root.com