From owner-freebsd-doc  Tue Feb 19  2: 0:12 2002
Delivered-To: freebsd-doc@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 7215E37B405
	for <freebsd-doc@freebsd.org>; Tue, 19 Feb 2002 02:00:02 -0800 (PST)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g1JA02g03965;
	Tue, 19 Feb 2002 02:00:02 -0800 (PST)
	(envelope-from gnats)
Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200])
	by hub.freebsd.org (Postfix) with ESMTP id 56C0637B404
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 19 Feb 2002 01:58:17 -0800 (PST)
Received: from pc4-card4-0-cust162.cdf.cable.ntl.com
	([80.4.14.162] helo=rhadamanth.private.submonkey.net ident=mailnull)
	by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2)
	id 16d72M-0004hj-00
	for FreeBSD-gnats-submit@freebsd.org; Tue, 19 Feb 2002 09:58:14 +0000
Received: from setantae by rhadamanth.private.submonkey.net with local (Exim 3.34 #1)
	id 16d72L-00017l-00
	for FreeBSD-gnats-submit@freebsd.org; Tue, 19 Feb 2002 09:58:13 +0000
Message-Id: <E16d72L-00017l-00@rhadamanth.private.submonkey.net>
Date: Tue, 19 Feb 2002 09:58:13 +0000
From: Ceri <setantae@submonkey.net>
Reply-To: Ceri <setantae@submonkey.net>
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.113
Subject: docs/35108: Developers' Handbook::VM chapter
Sender: owner-freebsd-doc@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-doc.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-doc>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-doc>
X-Loop: FreeBSD.org


>Number:         35108
>Category:       docs
>Synopsis:       Developers' Handbook::VM chapter
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 19 02:00:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Ceri <setantae@submonkey.net>
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
>Environment:
System: FreeBSD rhadamanth.private.submonkey.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Tue Feb 12 17:56:57 GMT 2002 setantae@rhadamanth.private.submonkey.net:/usr/obj/usr/src/sys/RHADAMANTH i386


	
>Description:

- Minor grammar fixes
- fix a couple of typos
- <literal> -> <option> for maxusers
- NOT -> <emphasis>not</emphasis>

Ceri

>How-To-Repeat:
	
>Fix:

--- doc/en_US.ISO8859-1/books/developers-handbook/vm/chapter.sgml.old	Tue Feb 19 09:16:49 2002
+++ doc/en_US.ISO8859-1/books/developers-handbook/vm/chapter.sgml	Tue Feb 19 09:40:59 2002
@@ -53,7 +53,7 @@
 	allocation at interrupt time.</para>
 
       <para>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
+	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
@@ -61,7 +61,7 @@
 
       <para>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 v.s. dirty pages.
+	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
@@ -89,7 +89,7 @@
 	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,
+	used to implement various sharing properties, including
 	copy-on-write, for forked address spaces.</para>
 
       <para>It should be noted that a <literal>vm_page_t</literal> can only be
@@ -106,12 +106,12 @@
 	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
+	its backing store.  Additionally, filesystems need to be able to map
 	portions of a file or file metadata into KVM in order to operate on
 	it.</para>
 
       <para>The entities used to manage this are known as filesystem buffers,
-	<literal>struct buf</literal>'s, and also known as
+	<literal>struct buf</literal>'s, or
 	<literal>bp</literal>'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
@@ -127,8 +127,8 @@
 	to hold mappings and does not limit the ability to cache data.
 	Physical data caching is strictly a function of
 	<literal>vm_page_t</literal>'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
+	since filesystem buffers are used to placehold I/O, they do inherently
+	limit the amount of concurrent I/O possible.  However, as there are usually a
 	few thousand filesystem buffers available, this is not usually a
 	problem.</para>
     </sect2>
@@ -147,13 +147,13 @@
 	<literal>vm_entry_t</literal> structures.  Page tables are directly
 	synthesized from the
 	<literal>vm_map_t</literal>/<literal>vm_entry_t</literal>/
-	<literal>vm_object_t</literal> hierarchy.  Remember when I mentioned
+	<literal>vm_object_t</literal> hierarchy.  Recall that I mentioned
 	that physical pages  are only directly associated with a
-	<literal>vm_object</literal>.  Well, that is not quite true.
+	<literal>vm_object</literal>; that is not quite true.
 	<literal>vm_page_t</literal>'s are also linked into page tables that
 	they are actively associated with.  One <literal>vm_page_t</literal>
 	can be linked into  several <emphasis>pmaps</emphasis>, as page tables
-	are called.  However, the hierarchical association holds so all
+	are called.  However, the hierarchical association holds, so all
 	references to the same page in the same object reference the same
 	<literal>vm_page_t</literal> and thus give us buffer cache unification
 	across the board.</para>
@@ -166,7 +166,7 @@
 	largest entity held in KVM is the filesystem buffer cache.  That is,
 	mappings relating to <literal>struct buf</literal> entities.</para>
 
-      <para>Unlike Linux, FreeBSD does NOT map all of physical memory into
+      <para>Unlike Linux, FreeBSD does <emphasis>not</emphasis> 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
@@ -186,23 +186,23 @@
       
       <para>A concerted effort has been made to make the FreeBSD kernel
 	dynamically tune itself.  Typically you do not need to mess with
-	anything beyond the <literal>maxusers</literal> and
-	<literal>NMBCLUSTERS</literal> kernel config options.  That is, kernel
+	anything beyond the <option>maxusers</option> and
+	<option>NMBCLUSTERS</option> kernel config options.  That is, kernel
 	compilation options specified in (typically)
 	<filename>/usr/src/sys/i386/conf/<replaceable>CONFIG_FILE</replaceable></filename>.
 	A description of all available kernel configuration options can be
 	found in <filename>/usr/src/sys/i386/conf/LINT</filename>.</para>
 
       <para>In a large system configuration you may wish to increase
-	<literal>maxusers</literal>.  Values typically range from 10 to 128.
-	Note that raising <literal>maxusers</literal> too high can cause the
+	<option>maxusers</option>.  Values typically range from 10 to 128.
+	Note that raising <option>maxusers</option> too high can cause the
 	system to overflow available KVM resulting in unpredictable operation.
-	It is better to leave maxusers at some reasonable number and add other
-	options, such as <literal>NMBCLUSTERS</literal>, to increase specific
+	It is better to leave <option>maxusers</option> at some reasonable number and add other
+	options, such as <option>NMBCLUSTERS</option>, to increase specific
 	resources.</para>
 
       <para>If your system is going to use the network heavily, you may want
-	to increase <literal>NMBCLUSTERS</literal>.  Typical values range from
+	to increase <option>NMBCLUSTERS</option>.  Typical values range from
 	1024 to 4096.</para>
 
       <para>The <literal>NBUF</literal> parameter is also traditionally used
@@ -232,8 +232,8 @@
 
       <para>Run time VM and system tuning is relatively straightforward.
 	First, use softupdates on your UFS/FFS filesystems whenever possible.
-	<filename>/usr/src/contrib/sys/softupdates/README</filename> contains
-	instructions (and restrictions) on how to configure it up.</para>
+	<filename>/usr/src/sys/ufs/ffs/README.softupdates</filename> contains
+	instructions (and restrictions) on how to configure it.</para>
 
       <para>Second, configure  sufficient swap.  You should have a swap
 	partition configured on each physical disk, up to four, even on your
>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message