Spelling police.
This commit is contained in:
parent
3f691d0dd2
commit
afc9adbc29
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=9825
1 changed files with 7 additions and 7 deletions
|
@ -1,4 +1,4 @@
|
|||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/vm-design/article.sgml,v 1.3 2001/01/24 11:50:30 ben Exp $ -->
|
||||
<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/vm-design/article.sgml,v 1.4 2001/02/20 19:49:32 nik Exp $ -->
|
||||
<!-- FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
|
@ -278,7 +278,7 @@
|
|||
completely overshadow it. If we fork again and create a set of D
|
||||
layers, however, it is much more likely that one of the D layers will
|
||||
eventually be able to completely overshadow the much smaller dataset
|
||||
reprsented by C1 or C2. The same optimization will work at any point in
|
||||
represented by C1 or C2. The same optimization will work at any point in
|
||||
the graph and the grand result of this is that even on a heavily forked
|
||||
machine VM Object stacks tend to not get much deeper then 4. This is
|
||||
true of both the parent and the children and true whether the parent is
|
||||
|
@ -559,7 +559,7 @@
|
|||
<question>
|
||||
<para>What is “the interleaving algorithm” that you
|
||||
refer to in your listing of the ills of the FreeBSD 3.x swap
|
||||
arrangments?</para>
|
||||
arrangements?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
|
@ -622,7 +622,7 @@
|
|||
to separate clean and dirty pages for the express reason of
|
||||
avoiding unnecessary flushes of dirty pages (which eats I/O
|
||||
bandwidth), nor does it move pages between the various page
|
||||
queues gratitously when the memory subsystem is not being
|
||||
queues gratuitously when the memory subsystem is not being
|
||||
stressed. This is why you will see some systems with very low
|
||||
cache queue counts and high active queue counts when doing a
|
||||
<command>systat -vm</command> command.</para>
|
||||
|
@ -691,7 +691,7 @@
|
|||
<literal>pv_entry</literal> structures.</para>
|
||||
|
||||
<para><literal>pv_entry</literal> structures only represent pages
|
||||
mapped by the MMU (one <literal>pv_entry</literal> represnts one
|
||||
mapped by the MMU (one <literal>pv_entry</literal> represents one
|
||||
pte). This means that when we need to remove all hardware
|
||||
references to a <literal>vm_page</literal> (in order to reuse the
|
||||
page for something else, page it out, clear it, dirty it, and so
|
||||
|
@ -779,8 +779,8 @@
|
|||
<emphasis>extremely</emphasis> important for most of a processor's
|
||||
memory accesses to be able to come from the L1 cache, because the
|
||||
L1 cache operates at the processor frequency. The moment you have
|
||||
an L1 cahe miss and have to go to the L2 cache or to main memory,
|
||||
the processor will stall and potentially sit twidling its fingers
|
||||
an L1 cache miss and have to go to the L2 cache or to main memory,
|
||||
the processor will stall and potentially sit twiddling its fingers
|
||||
for <emphasis>hundreds</emphasis> of instructions worth of time
|
||||
waiting for a read from main memory to complete. Main memory (the
|
||||
dynamic ram you stuff into a computer) is
|
||||
|
|
Loading…
Reference in a new issue