os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

X.x -> X.X when mentioning FreeBSD branches to be consistent with the

Browse source 
rest of the doc tree.

PR:		38777
Submitted by:	blackend
This commit is contained in:
Jim Mock 2002-07-03 23:19:12 +00:00
parent 279f2c4ab8
commit 7e5229d6dc
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13558
4 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
en_US.ISO8859-1/articles/committers-guide/article.sgml
View file

@ -76,7 +76,7 @@
<row>
<entry><emphasis>Noteworthy CVS Tags</emphasis></entry>
<entry><literal>RELENG_4</literal> (4.x-STABLE), <literal>HEAD</literal> (-CURRENT)</entry>
<entry><literal>RELENG_4</literal> (4.X-STABLE), <literal>HEAD</literal> (-CURRENT)</entry>
</row>
</tbody>
</tgroup>
@ -319,7 +319,7 @@
<listitem>
<para>Check out the <filename>miscfs</filename> module as
it is in the 4.x branch:</para>
it is in the 4.X branch:</para>
<screen>&prompt.user; <userinput>cvs co -rRELENG_4 miscfs</userinput></screen>
@ -579,11 +579,11 @@
</itemizedlist>
<para>You will almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $</literal> (or in FreeBSD's case,
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit
the file to resolve the conflict (remove the marker lines and
the second <literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $</literal> line intact).</para>
the second <literal>$Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $</literal> line intact).</para>
</listitem>
<listitem>

2
en_US.ISO8859-1/articles/java-tomcat/article.sgml
View file

@ -118,7 +118,7 @@
<para>The Tomcat portion of the install is very straight forward, but
the difficulty I had was getting Java Development Kit up and
running for FreeBSD 4.x, as Sun Microsystems only supplies
running for FreeBSD 4.X, as Sun Microsystems only supplies
Binaries for Linux, Solaris, and Windows NT. This means that I
had to compile my own JDK for FreeBSD. I began by searching for
documentation on the Internet. I quickly found that there is more

4
en_US.ISO8859-1/articles/releng/branches.ascii
View file

@ -8,7 +8,7 @@ $FreeBSD$
| RELENG_3
H ______|____ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + - - - - - - +
E / \ | | | | | | | | | | | |
A |3.1-RELEASE|-|3.2R |-|3.3R |-|3.4R |-|3.5R |-| 3.5.1R|---| 3.x-STABLE |
A |3.1-RELEASE|-|3.2R |-|3.3R |-|3.4R |-|3.5R |-| 3.5.1R|---| 3.X-STABLE |
D \___________/ |_ _ _| |_ _ _| |_ _ _| |_ _ _| |_ _ _ _| | |
| + - - - - - - +
|
@ -19,7 +19,7 @@ D \___________/ |_ _ _| |_ _ _| |_ _ _| |_ _ _| |_ _ _ _| | |
| RELENG_4
_____|_____ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + - - - - - - +
/ \ | | | | | | | | | | | |
|4.0-RELEASE|-|4.1R |-|4.1.1R |-|4.2R |-|4.3R |-|4.4R |---| 4.x-STABLE |
|4.0-RELEASE|-|4.1R |-|4.1.1R |-|4.2R |-|4.3R |-|4.4R |---| 4.X-STABLE |
\___________/ |_ _ _| |_ _ _ _| |_ _ _| |_ _ _| |_ _ _| | |
| ___| |__ + - - - - - - +
| _ _ _ | _ _ _ _ _ |_ _ _ __

14
en_US.ISO8859-1/articles/vm-design/article.sgml
View file

@ -312,7 +312,7 @@
However, the swap management structure has had problems
historically.</para>
<para>Under FreeBSD 3.x the swap management structure preallocates an
<para>Under FreeBSD 3.X the swap management structure preallocates an
array that encompasses the entire object requiring swap backing
store&mdash;even if only a few pages of that object are swap-backed.
This creates a kernel memory fragmentation problem when large objects
@ -329,7 +329,7 @@
fly for additional swap management structures when a swapout occurs. It
is evident that there was plenty of room for improvement.</para>
<para>For FreeBSD 4.x, I completely rewrote the swap subsystem. With this
<para>For FreeBSD 4.X, I completely rewrote the swap subsystem. With this
rewrite, swap management structures are allocated through a hash table
rather than a linear array giving them a fixed allocation size and much
finer granularity. Rather then using a linearly linked list to keep
@ -558,7 +558,7 @@
<qandaentry>
<question>
<para>What is <quote>the interleaving algorithm</quote> that you
refer to in your listing of the ills of the FreeBSD 3.x swap
refer to in your listing of the ills of the FreeBSD 3.X swap
arrangements?</para>
</question>
@ -574,7 +574,7 @@
<literallayout>A B C D A B C D A B C D A B C D</literallayout>
<para>FreeBSD 3.x uses a <quote>sequential list of free
<para>FreeBSD 3.X uses a <quote>sequential list of free
regions</quote> approach to accounting for the free swap areas.
The idea is that large blocks of free linear space can be
represented with a single list node
@ -593,16 +593,16 @@
it is to try to put that sophistication elsewhere.</para>
<para>The fragmentation causes other problems. Being a linear list
under 3.x, and having such a huge amount of inherent
under 3.X, and having such a huge amount of inherent
fragmentation, allocating and freeing swap winds up being an O(N)
algorithm instead of an O(1) algorithm. Combined with other
factors (heavy swapping) and you start getting into O(N^2) and
O(N^3) levels of overhead, which is bad. The 3.x system may also
O(N^3) levels of overhead, which is bad. The 3.X system may also
need to allocate KVM during a swap operation to create a new list
node which can lead to a deadlock if the system is trying to
pageout pages in a low-memory situation.</para>
<para>Under 4.x we do not use a sequential list. Instead we use a
<para>Under 4.X we do not use a sequential list. Instead we use a
radix tree and bitmaps of swap blocks rather than ranged list
nodes. We take the hit of preallocating all the bitmaps required
for the entire swap area up front but it winds up wasting less