diff --git a/en_US.ISO8859-1/articles/committers-guide/article.sgml b/en_US.ISO8859-1/articles/committers-guide/article.sgml index 2722e67321..571052f549 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.sgml +++ b/en_US.ISO8859-1/articles/committers-guide/article.sgml @@ -76,7 +76,7 @@ Noteworthy CVS Tags - RELENG_4 (4.x-STABLE), HEAD (-CURRENT) + RELENG_4 (4.X-STABLE), HEAD (-CURRENT) @@ -319,7 +319,7 @@ Check out the miscfs module as - it is in the 4.x branch: + it is in the 4.X branch: &prompt.user; cvs co -rRELENG_4 miscfs @@ -579,11 +579,11 @@ You will almost certainly get a conflict because - of the $Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $ (or in FreeBSD's case, + of the $Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $ (or in FreeBSD's case, $FreeBSD$) lines, so you will have to edit the file to resolve the conflict (remove the marker lines and - the second $Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $ line, leaving the original - $Id: article.sgml,v 1.128 2002-07-02 00:04:18 trhodes Exp $ line intact). + the second $Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $ line, leaving the original + $Id: article.sgml,v 1.129 2002-07-03 23:19:04 jim Exp $ line intact). diff --git a/en_US.ISO8859-1/articles/java-tomcat/article.sgml b/en_US.ISO8859-1/articles/java-tomcat/article.sgml index 43927b007e..c28562cd2c 100644 --- a/en_US.ISO8859-1/articles/java-tomcat/article.sgml +++ b/en_US.ISO8859-1/articles/java-tomcat/article.sgml @@ -118,7 +118,7 @@ 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 diff --git a/en_US.ISO8859-1/articles/releng/branches.ascii b/en_US.ISO8859-1/articles/releng/branches.ascii index 1f3f198a58..531bed46bf 100644 --- a/en_US.ISO8859-1/articles/releng/branches.ascii +++ b/en_US.ISO8859-1/articles/releng/branches.ascii @@ -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 | \___________/ |_ _ _| |_ _ _ _| |_ _ _| |_ _ _| |_ _ _| | | | ___| |__ + - - - - - - + | _ _ _ | _ _ _ _ _ |_ _ _ __ diff --git a/en_US.ISO8859-1/articles/vm-design/article.sgml b/en_US.ISO8859-1/articles/vm-design/article.sgml index 9e992c6039..f4f2487d4b 100644 --- a/en_US.ISO8859-1/articles/vm-design/article.sgml +++ b/en_US.ISO8859-1/articles/vm-design/article.sgml @@ -312,7 +312,7 @@ However, the swap management structure has had problems historically. - Under FreeBSD 3.x the swap management structure preallocates an + Under FreeBSD 3.X the swap management structure preallocates an array that encompasses the entire object requiring swap backing store—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. - For FreeBSD 4.x, I completely rewrote the swap subsystem. With this + 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 @@ What is the interleaving algorithm 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? @@ -574,7 +574,7 @@ A B C D A B C D A B C D A B C D - FreeBSD 3.x uses a sequential list of free + FreeBSD 3.X uses a sequential list of free regions 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. 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. - Under 4.x we do not use a sequential list. Instead we use a + 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