Date: Tue, 19 Feb 2002 09:58:13 +0000 From: Ceri <setantae@submonkey.net> To: FreeBSD-gnats-submit@freebsd.org Subject: docs/35108: Developers' Handbook::VM chapter Message-ID: <E16d72L-00017l-00@rhadamanth.private.submonkey.net>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E16d72L-00017l-00>