diff --git a/handbook/Makefile b/handbook/Makefile index f36417cd90..2cb98f0386 100644 --- a/handbook/Makefile +++ b/handbook/Makefile @@ -1,22 +1,22 @@ -# $Id: Makefile,v 1.33 1998-07-23 10:27:04 wosch Exp $ +# $Id: Makefile,v 1.34 1999-02-06 20:20:16 dillon Exp $ .NOTPARALLEL: SGMLOPTS=-links SRCS= anoncvs.sgml authors.sgml backups.sgml basics.sgml bibliography.sgml SRCS+= boothelp.sgml booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml SRCS+= cvsup.sgml cyclades.sgml development.sgml dialup.sgml dialout.sgml SRCS+= disks.sgml diskless.sgml dma.sgml eresources.sgml esdi.sgml SRCS+= firewalls.sgml german.sgml glossary.sgml goals.sgml SRCS+= handbook.sgml history.sgml hw.sgml install.sgml isdn.sgml SRCS+= kerberos.sgml kernelconfig.sgml kerneldebug.sgml kernelopts.sgml -SRCS+= lists.sgml mail.sgml makeworld.sgml memoryuse.sgml +SRCS+= lists.sgml mail.sgml makeworld.sgml memoryuse.sgml vm.sgml SRCS+= mirrors.sgml nfs.sgml nutshell.sgml pgpkeys.sgml policies.sgml SRCS+= porting.sgml ports.sgml ppp.sgml printing.sgml SRCS+= quotas.sgml relnotes.sgml routing.sgml russian.sgml SRCS+= serial.sgml scsi.sgml scsihd.sgml SRCS+= sections.sgml sio.sgml skey.sgml slipc.sgml SRCS+= slips.sgml stable.sgml submitters.sgml synching.sgml SRCS+= term.sgml userppp.sgml uart.sgml linuxemu.sgml .include diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index f0c8438ab1..7c02bb2c5b 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,193 +1,194 @@ - + %authors; %lists; %sections; ]> FreeBSD Handbook The FreeBSD Documentation Project February 1999 Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD Release &rel.current;. This manual is a work in progress and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the &a.doc; . The latest version of this document is always available from the . It may also be downloaded in , , PDF or with HTTP or gzip'd from the . or one of the numerous . You may also want to . Getting Started Introduction

FreeBSD is a 4.4BSD-Lite based operating system for Intel architecture (x86) based PCs. For an overview of FreeBSD, see . For a history of the project, read . To see a description of the latest release, read . If you're interested in contributing something to the FreeBSD project (code, equipment, sacks of unmarked bills), please see about . &nutshell; &history; &goals; &development; &relnotes; &install; &basics; &ports; System Administration &kernelconfig; Security &crypt; &skey; &kerberos; &firewalls; &printing; &disks; &backups; "as; The X Window System

Pending the completion of this section, please refer to documentation supplied by the . &hw; Localization &russian; &german; Network Communications Serial Communications &serial; &term; &dialup; &dialout; PPP and SLIP

If your connection to the Internet is through a modem, or you wish to provide other people with dialup connections to the Internet using FreeBSD, you have the option of using PPP or SLIP. Furthermore, two varieties of PPP are provided: user (sometimes referred to as iijppp) and kernel. The procedures for configuring both types of PPP, and for setting up SLIP are described in this chapter. &userppp; &ppp; &slipc; &slips; Advanced Networking &routing; &nfs; &diskless; &isdn; &mail; Advanced topics The Cutting Edge: FreeBSD-current and FreeBSD-stable

FreeBSD is under constant development between releases. For people who want to be on the cutting edge, there are several easy mechanisms for keeping your system in sync with the latest developments. Be warned: the cutting edge is not for everyone! This chapter will help you decide if you want to track the development system, or stick with one of the released versions.

¤t; &stable; &synching; &makeworld; &submitters; &policies; &kernelopts; &kerneldebug; &linuxemu; FreeBSD Internals &booting; &memoryuse; + &vm; &dma; Appendices &mirrors; &bibliography; &eresources; &contrib; &pgpkeys; diff --git a/handbook/sections.sgml b/handbook/sections.sgml index 9991885cf2..5825ea6dc8 100644 --- a/handbook/sections.sgml +++ b/handbook/sections.sgml @@ -1,67 +1,68 @@ - + + diff --git a/handbook/vm.sgml b/handbook/vm.sgml new file mode 100644 index 0000000000..6cd03e8c6f --- /dev/null +++ b/handbook/vm.sgml @@ -0,0 +1,165 @@ + + + +The FreeBSD VM System + +

Contributed by &a.dillon;. + 6 Feb 1999. + +An involved description of FreeBSD's VM internals + +Management of physical memory - vm_page_t + +

+ Physical memory is managed on a page-by-page basis through the + vm_page_t structure. Pages of physical memory are + categorized through the placement of their respective vm_page_t + structures on one of several paging queues. +

+ A page can be in a wired, active, inactive, cache, or free state. + Except for the wired state, the page is typically placed in a doubly + link list queue representing the state that it is in. Wired pages + are not placed on any queue. +

+ FreeBSD implements a more involved paging queue for cached and free + pages in order to implement page coloring. Each of these states + involves multiple queues arranged according to the size of the + processor's L1 and L2 caches. When a new page needs to be allocated, + FreeBSD attempts to obtain one that is reasonably well aligned from + the point of view of the L1 and L2 caches relative to the VM object the + page is being allocated for. +

+ Additionally, a page may be held with a reference count or locked + with a busy count. The VM system also implements an 'ultimate locked' + state for a page using the PG_BUSY bit in the page's flags. +

+ In general terms, each of the paging queues operates in a LRU fashion. + A page is typicaly placed in a wired or active state initially. When + wired, the page is usually associated with a page table somewhere. + The VM system ages the page by scanning pages in a more active paging + queue (LRU) in order to move them to a less-active paging queue. Pages + that get moved into the cache are still associated with a VM object + but are candidates for immediate reuse. Pages in the free queue are + truely free. FreeBSD attempts to minimize the number of pages in the + free queue, but a certain minimum number of truely free pages must be + maintained in order to accomodate page allocation at interrupt time. +

+ If a process attempts to access a page that does not exist in its + page table but does exist in one of the paging queues ( such as the + inactive or cache queues), a relatively inexpensive page reactivation + fault occurs which causes the page to be reactivated. If the page + does not exist in system memory at all, the process must block while + the page is brought in from disk. +

+ FreeBSD dynamically tunes its paging queues and attempts to maintain + reasonable ratios of pages in the various queues as well as attempts + to maintain a reasonable breakdown of clean vs dirty pages. The + amount of rebalancing that occurs depends on the system's memory load. + This rebalancing is implemented by the pageout daemon and involves + laundering dirty pages ( syncing them with their backing store ), + noticing when pages are activity referenced ( resetting their position + in the LRU queues or moving them between queues ), migrating pages + between queues when the queues are out of balance, and so forth. + FreeBSD's VM system is willing to take a reasonable number of + reactivation page faults to determine how active or how idle a page + actually is. This leads to better decisions being made as to when + to launder or swap-out a page. + +The unified buffer cache - vm_object_t + +

+ FreeBSD implements the idea of a generic 'VM object'. VM objects + can be associated with backing store of various types - unbacked, + swap-backed, physical device-backed, or file-backed storage. Since + the filesystem uses the same VM objects to manage in-core data relating + to files, the result is a unified buffer cache. +

+ VM objects can be shadowed. That is, they can be stacked on + top of each other. For example, you might have a swap-backed VM object + stacked on top of a file-backed VM object in order to implement a + MAP_PRIVATE mmap()ing. This stacking is also used to implement various + sharing properties, including, copy-on-write, for forked address + spaces. +

+ It should be noted that a vm_page_t can only be associated with one + VM object at a time. The VM object shadowing implements the + perceived sharing of the same page across multiple instances. + +Filesystem I/O - struct buf + +

+ vnode-backed VM objects, such as file-backed objects, generally need + to maintain their own clean/dirty info independant from the VM system's + idea of clean/dirty. For example, when the VM system decides to + synchronize a physical page to its backing store, the VM system needs + to mark the page clean before the page is actually written to its + backing s tore. Additionally, filesystems need to be able to map + portions of a file or file metadata into KVM in order to operate on it. +

+ The entities used to manage this are known as filesystem buffers, + struct buf's, and also known as bp's. When a + filesystem needs to operate on a portion of a VM object, it typically + maps part of the object into a struct buf and the maps the pages in + the struct buf into KVM. In the same manner, disk I/O is typically + issued by mapping portions of objects into buffer structures and + then issuing the I/O on the buffer structures. The underlying + vm_page_t's are typically busied for the duration of the I/O. + Filesystem buffers also have their own notion of being busy, which + is useful to filesystem driver code which would rather operate on + filesystem buffers instead of hard VM pages. +

+ FreeBSD reserves a limited amount of KVM to hold mappings from struct + bufs, but it should be made clear that this KVM is used solely to + hold mappings and does not limit the ability to cache data. Physical + data caching is strictly a function of vm_page_t's, not filesystem + buffers. However, since filesystem buffers are used placehold I/O, + they do inherently limit the amount of concurrent I/O possible. As + there are usually a few thousand filesystem buffers available, this + is not usually a problem. + +Mapping Page Tables - vm_map_t, vm_entry_t + +

+ FreeBSD separates the physical page table topology from the VM + system. All hard per-process page tables can be reconstructed on + the fly and are usually considered throwaway. Special page tables + such as those managing KVM are typically permanently preallocated. + These page tables are not throwaway. +

+ FreeBSD associates portions of vm_objects with address ranges in + virtual memory through vm_map_t and vm_entry_t structures. Page + tables are directly synthesized from the vm_map_t/vm_entry_t/ + vm_object_t hierarchy. Remember when I mentioned that physical pages + are only directly associated with a vm_object. Well, that isn't + quite true. vm_page_t's are also linked into page tables that they + are actively associated with. One vm_page_t can be linked into + several pmaps, as page tables are called. However, the + hierarchical association holds so all references to the same + page in the same object reference the same vm_page_t and thus give + us buffer cache unification across the board. + +KVM Memory Mapping + +

+ FreeBSD uses KVM to hold various kernel structures. The single + largest entity held in KVM is the filesystem buffer cache. That is, + mappings relating to struct buf entities. +

+ Unlike Linux, FreeBSD does NOT map all of physical memory into KVM. + This means that FreeBSD can handle memory configurations up to 4G + on 32 bit platforms. In fact, if the mmu were capable of it, FreeBSD + could theoretically handle memory configurations up to 8TB on a 32 + bit platform. However, since most 32 bit platforms are only capable + of mapping 4GB of ram, this is a moot point. +

+ KVM is managed through several mechanisms. The main mechanism used to + manage KVM is the zone allocator. The zone allocator takes + a chunk of KVM and splits it up into constant-sized blocks of memory + in order to allocate a specific type of structure. You can use the + vmstat -m command to get an overview of current KVM + utilization broken down by zone. +

+ +Contributed by &a.dillon;. + 6 Feb 1999. +