PERFORCE change 179851 for review
Rene Ladan
rene at FreeBSD.org
Sat Jun 19 18:40:57 UTC 2010
http://p4web.freebsd.org/@@179851?ac=10
Change 179851 by rene at rene_acer on 2010/06/19 18:40:48
IFC
Affected files ...
.. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#60 integrate
.. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/vm-design/article.sgml#2 integrate
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml#4 integrate
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml#14 integrate
.. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml#9 integrate
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#33 integrate
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml#49 integrate
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#30 integrate
.. //depot/projects/docproj_nl/share/sgml/mirrors.xml#19 integrate
.. //depot/projects/docproj_nl/www/en/gnome/docs/faq2.sgml#6 integrate
.. //depot/projects/docproj_nl/www/en/platforms/ppc.sgml#5 integrate
.. //depot/projects/docproj_nl/www/nl/where.sgml#20 integrate
.. //depot/projects/docproj_nl/www/share/sgml/commercial.consult.xml#23 integrate
.. //depot/projects/docproj_nl/www/share/sgml/news.dtd#2 integrate
.. //depot/projects/docproj_nl/www/share/sgml/news.xml#82 integrate
.. //depot/projects/docproj_nl/www/share/sgml/release.ent#26 integrate
Differences ...
==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#60 (text+ko) ====
@@ -1,4 +1,4 @@
-<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml,v 1.917 2010/06/11 11:15:14 ashish Exp $ -->
+<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml,v 1.918 2010/06/17 14:21:15 osa Exp $ -->
<!--
NOTE TO COMMITTERS: Contributors lists are sorted in alphabetical
order by first name.
@@ -3888,6 +3888,11 @@
</listitem>
<listitem>
+ <para>Ildar Hizbulin
+ <email>hizel at vyborg.ru</email></para>
+ </listitem>
+
+ <listitem>
<para>Ilia Chipitsine
<email>ilia at rediska.ru</email></para>
</listitem>
==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/vm-design/article.sgml#2 (text+ko) ====
@@ -1,4 +1,4 @@
-<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/vm-design/article.sgml,v 1.16 2006/09/24 13:36:59 danger Exp $ -->
+<!-- $FreeBSD: doc/en_US.ISO8859-1/articles/vm-design/article.sgml,v 1.18 2010/06/17 11:24:25 jkois Exp $ -->
<!-- FreeBSD Documentation Project -->
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@@ -8,7 +8,7 @@
<article>
<articleinfo>
- <title>Design elements of the FreeBSD VM system</title>
+ <title>Design elements of the &os; VM system</title>
<authorgroup>
<author>
@@ -36,7 +36,7 @@
<para>The title is really just a fancy way of saying that I am going to
attempt to describe the whole VM enchilada, hopefully in a way that
everyone can follow. For the last year I have concentrated on a number
- of major kernel subsystems within FreeBSD, with the VM and Swap
+ of major kernel subsystems within &os;, with the VM and Swap
subsystems being the most interesting and NFS being <quote>a necessary
chore</quote>. I rewrote only small portions of the code. In the VM
arena the only major rewrite I have done is to the swap subsystem.
@@ -53,7 +53,7 @@
<para>This article was originally published in the January 2000 issue of
<ulink url="http://www.daemonnews.org/">DaemonNews</ulink>. This
version of the article may include updates from Matt and other authors
- to reflect changes in FreeBSD's VM implementation.</para>
+ to reflect changes in &os;'s VM implementation.</para>
</legalnotice>
</articleinfo>
@@ -71,7 +71,7 @@
operating system by some people, those of us who work on it tend to view
it more as a <quote>mature</quote> codebase which has various components
modified, extended, or replaced with modern code. It has evolved, and
- FreeBSD is at the bleeding edge no matter how old some of the code might
+ &os; is at the bleeding edge no matter how old some of the code might
be. This is an important distinction to make and one that is
unfortunately lost to many people. The biggest error a programmer can
make is to not learn from history, and this is precisely the error that
@@ -89,35 +89,46 @@
right because our marketing department says so</quote>. I have little
tolerance for anyone who cannot learn from history.</para>
- <para>Much of the apparent complexity of the FreeBSD design, especially in
+ <para>Much of the apparent complexity of the &os; design, especially in
the VM/Swap subsystem, is a direct result of having to solve serious
performance issues that occur under various conditions. These issues
are not due to bad algorithmic design but instead rise from
environmental factors. In any direct comparison between platforms,
these issues become most apparent when system resources begin to get
- stressed. As I describe FreeBSD's VM/Swap subsystem the reader should
- always keep two points in mind. First, the most important aspect of
- performance design is what is known as <quote>Optimizing the Critical
- Path</quote>. It is often the case that performance optimizations add a
- little bloat to the code in order to make the critical path perform
- better. Second, a solid, generalized design outperforms a
- heavily-optimized design over the long run. While a generalized design
- may end up being slower than an heavily-optimized design when they are
- first implemented, the generalized design tends to be easier to adapt to
- changing conditions and the heavily-optimized design winds up having to
- be thrown away. Any codebase that will survive and be maintainable for
+ stressed. As I describe &os;'s VM/Swap subsystem the reader should
+ always keep two points in mind:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>The most important aspect of performance design is what is
+ known as <quote>Optimizing the Critical Path</quote>. It is often
+ the case that performance optimizations add a little bloat to the
+ code in order to make the critical path perform better.</para>
+ </listitem>
+
+ <listitem>
+ <para>A solid, generalized design outperforms a heavily-optimized
+ design over the long run. While a generalized design may end up
+ being slower than an heavily-optimized design when they are
+ first implemented, the generalized design tends to be easier to
+ adapt to changing conditions and the heavily-optimized design
+ winds up having to be thrown away.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Any codebase that will survive and be maintainable for
years must therefore be designed properly from the beginning even if it
costs some performance. Twenty years ago people were still arguing that
programming in assembly was better than programming in a high-level
language because it produced code that was ten times as fast. Today,
- the fallibility of that argument is obvious—as are the parallels
- to algorithmic design and code generalization.</para>
+ the fallibility of that argument is obvious — as are
+ the parallels to algorithmic design and code generalization.</para>
</sect1>
<sect1 id="vm-objects">
<title>VM Objects</title>
- <para>The best way to begin describing the FreeBSD VM system is to look at
+ <para>The best way to begin describing the &os; VM system is to look at
it from the perspective of a user-level process. Each user process sees
a single, private, contiguous VM address space containing several types
of memory objects. These objects have various characteristics. Program
@@ -157,7 +168,7 @@
(parent and child) expects their own personal post-fork modifications to
remain private to themselves and not effect the other.</para>
- <para>FreeBSD manages all of this with a layered VM Object model. The
+ <para>&os; manages all of this with a layered VM Object model. The
original binary program file winds up being the lowest VM Object layer.
A copy-on-write layer is pushed on top of that to hold those pages which
had to be copied from the original file. If the program modifies a data
@@ -235,7 +246,7 @@
The original page in B is now completely hidden since both C1 and C2
have a copy and B could theoretically be destroyed if it does not
represent a <quote>real</quote> file; however, this sort of optimization is not
- trivial to make because it is so fine-grained. FreeBSD does not make
+ trivial to make because it is so fine-grained. &os; does not make
this optimization. Now, suppose (as is often the case) that the child
process does an <function>exec()</function>. Its current address space
is usually replaced by a new address space representing a new file. In
@@ -274,7 +285,7 @@
get their own private copies of the page and the original page in B is
no longer accessible by anyone. That page in B can be freed.</para>
- <para>FreeBSD solves the deep layering problem with a special optimization
+ <para>&os; solves the deep layering problem with a special optimization
called the <quote>All Shadowed Case</quote>. This case occurs if either
C1 or C2 take sufficient COW faults to completely shadow all pages in B.
Lets say that C1 achieves this. C1 can now bypass B entirely, so rather
@@ -303,7 +314,7 @@
copying need take place. The disadvantage is that you can build a
relatively complex VM Object layering that slows page fault handling
down a little, and you spend memory managing the VM Object structures.
- The optimizations FreeBSD makes proves to reduce the problems enough
+ The optimizations &os; makes proves to reduce the problems enough
that they can be ignored, leaving no real disadvantage.</para>
</sect1>
@@ -315,43 +326,88 @@
backing object (usually a file) can no longer be used to save a copy of
the page when the VM system needs to reuse it for other purposes. This
is where SWAP comes in. SWAP is allocated to create backing store for
- memory that does not otherwise have it. FreeBSD allocates the swap
+ memory that does not otherwise have it. &os; allocates the swap
management structure for a VM Object only when it is actually needed.
However, the swap management structure has had problems
- historically.</para>
+ historically:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Under &os; 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 are mapped, or processes with large runsizes
+ (RSS) fork.</para>
+ </listitem>
+
+ <listitem>
+ <para>Also, in order to keep track of swap space, a <quote>list of
+ holes</quote> is kept in kernel memory, and this tends to get
+ severely fragmented as well. Since the <quote>list of
+ holes</quote> is a linear list, the swap allocation and freeing
+ performance is a non-optimal O(n)-per-page.</para>
+ </listitem>
+
+ <listitem>
+ <para>It requires kernel memory allocations to take place during
+ the swap freeing process, and that creates low memory deadlock
+ problems.</para>
+ </listitem>
+
+ <listitem>
+ <para>The problem is further exacerbated by holes created due to
+ the interleaving algorithm.</para>
+ </listitem>
+
+ <listitem>
+ <para>Also, the swap block map can become fragmented fairly easily
+ resulting in non-contiguous allocations.</para>
+ </listitem>
+
+ <listitem>
+ <para>Kernel memory must also be allocated on the fly for additional
+ swap management structures when a swapout occurs.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>It is evident from that list that there was plenty of room for
+ improvement. For &os; 4.X, I completely rewrote the swap
+ subsystem:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Swap management structures are allocated through a hash
+ table rather than a linear array giving them a fixed allocation
+ size and much finer granularity.</para>
+ </listitem>
+
+ <listitem>
+ <para>Rather then using a linearly linked list to keep track of
+ swap space reservations, it now uses a bitmap of swap blocks
+ arranged in a radix tree structure with free-space hinting in
+ the radix node structures. This effectively makes swap
+ allocation and freeing an O(1) operation.</para>
+ </listitem>
+
+ <listitem>
+ <para>The entire radix tree bitmap is also preallocated in
+ order to avoid having to allocate kernel memory during critical
+ low memory swapping operations. After all, the system tends to
+ swap when it is low on memory so we should avoid allocating
+ kernel memory at such times in order to avoid potential
+ deadlocks.</para>
+ </listitem>
- <para>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
- are mapped, or processes with large runsizes (RSS) fork. Also, in order
- to keep track of swap space, a <quote>list of holes</quote> is kept in
- kernel memory, and this tends to get severely fragmented as well. Since
- the <quote>list of holes</quote> is a linear list, the swap allocation and freeing
- performance is a non-optimal O(n)-per-page. It also requires kernel
- memory allocations to take place during the swap freeing process, and
- that creates low memory deadlock problems. The problem is further
- exacerbated by holes created due to the interleaving algorithm. Also,
- the swap block map can become fragmented fairly easily resulting in
- non-contiguous allocations. Kernel memory must also be allocated on the
- fly for additional swap management structures when a swapout occurs. It
- is evident that there was plenty of room for improvement.</para>
+ <listitem>
+ <para>To reduce fragmentation the radix tree is capable
+ of allocating large contiguous chunks at once, skipping over
+ smaller fragmented chunks.</para>
+ </listitem>
+ </itemizedlist>
- <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
- track of swap space reservations, it now uses a bitmap of swap blocks
- arranged in a radix tree structure with free-space hinting in the radix
- node structures. This effectively makes swap allocation and freeing an
- O(1) operation. The entire radix tree bitmap is also preallocated in
- order to avoid having to allocate kernel memory during critical low
- memory swapping operations. After all, the system tends to swap when it
- is low on memory so we should avoid allocating kernel memory at such
- times in order to avoid potential deadlocks. Finally, to reduce
- fragmentation the radix tree is capable of allocating large contiguous
- chunks at once, skipping over smaller fragmented chunks. I did not take
- the final step of having an <quote>allocating hint pointer</quote> that would trundle
+ <para>I did not take the final step of having an
+ <quote>allocating hint pointer</quote> that would trundle
through a portion of swap as allocations were made in order to further
guarantee contiguous allocations or at least locality of reference, but
I ensured that such an addition could be made.</para>
@@ -373,7 +429,7 @@
hundreds of thousands of CPU cycles and a noticeable stall of the
affected processes, so we are willing to endure a significant amount of
overhead in order to be sure that the right page is chosen. This is why
- FreeBSD tends to outperform other systems when memory resources become
+ &os; tends to outperform other systems when memory resources become
stressed.</para>
<para>The free page determination algorithm is built upon a history of the
@@ -403,10 +459,10 @@
then have to go to disk.</para>
</sidebar>
- <para>FreeBSD makes use of several page queues to further refine the
+ <para>&os; makes use of several page queues to further refine the
selection of pages to reuse as well as to determine when dirty pages
must be flushed to their backing store. Since page tables are dynamic
- entities under FreeBSD, it costs virtually nothing to unmap a page from
+ entities under &os;, it costs virtually nothing to unmap a page from
the address space of any processes using it. When a page candidate has
been chosen based on the page-use counter, this is precisely what is
done. The system must make a distinction between clean pages which can
@@ -423,7 +479,7 @@
in an LRU (least-recently used) fashion when the system needs to
allocate new memory.</para>
- <para>It is important to note that the FreeBSD VM system attempts to
+ <para>It is important to note that the &os; VM system attempts 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 gratuitously when the
@@ -431,10 +487,12 @@
systems with very low cache queue counts and high active queue counts
when doing a <command>systat -vm</command> command. As the VM system
becomes more stressed, it makes a greater effort to maintain the various
- page queues at the levels determined to be the most effective. An urban
+ page queues at the levels determined to be the most effective.</para>
+
+ <para>An urban
myth has circulated for years that Linux did a better job avoiding
- swapouts than FreeBSD, but this in fact is not true. What was actually
- occurring was that FreeBSD was proactively paging out unused pages in
+ swapouts than &os;, but this in fact is not true. What was actually
+ occurring was that &os; was proactively paging out unused pages in
order to make room for more disk cache while Linux was keeping unused
pages in core and leaving less memory available for cache and process
pages. I do not know whether this is still true today.</para>
@@ -451,9 +509,9 @@
not mapped into the page table, then all the pages that will be accessed
by the program will have to be faulted in every time the program is run.
This is unnecessary when the pages in question are already in the VM
- Cache, so FreeBSD will attempt to pre-populate a process's page tables
+ Cache, so &os; will attempt to pre-populate a process's page tables
with those pages that are already in the VM Cache. One thing that
- FreeBSD does not yet do is pre-copy-on-write certain pages on exec. For
+ &os; does not yet do is pre-copy-on-write certain pages on exec. For
example, if you run the &man.ls.1; program while running <command>vmstat
1</command> you will notice that it always takes a certain number of
page faults, even when you run it over and over again. These are
@@ -480,7 +538,7 @@
<title>Page Table Optimizations</title>
<para>The page table optimizations make up the most contentious part of
- the FreeBSD VM design and they have shown some strain with the advent of
+ the &os; VM design and they have shown some strain with the advent of
serious use of <function>mmap()</function>. I think this is actually a
feature of most BSDs though I am not sure when it was first introduced.
There are two major optimizations. The first is that hardware page
@@ -488,23 +546,23 @@
any time with only a minor amount of management overhead. The second is
that every active page table entry in the system has a governing
<literal>pv_entry</literal> structure which is tied into the
- <literal>vm_page</literal> structure. FreeBSD can simply iterate
+ <literal>vm_page</literal> structure. &os; can simply iterate
through those mappings that are known to exist while Linux must check
all page tables that <emphasis>might</emphasis> contain a specific
mapping to see if it does, which can achieve O(n^2) overhead in certain
- situations. It is because of this that FreeBSD tends to make better
+ situations. It is because of this that &os; tends to make better
choices on which pages to reuse or swap when memory is stressed, giving
- it better performance under load. However, FreeBSD requires kernel
+ it better performance under load. However, &os; requires kernel
tuning to accommodate large-shared-address-space situations such as
those that can occur in a news system because it may run out of
<literal>pv_entry</literal> structures.</para>
- <para>Both Linux and FreeBSD need work in this area. FreeBSD is trying to
+ <para>Both Linux and &os; need work in this area. &os; is trying to
maximize the advantage of a potentially sparse active-mapping model (not
all processes need to map all pages of a shared library, for example),
- whereas Linux is trying to simplify its algorithms. FreeBSD generally
+ whereas Linux is trying to simplify its algorithms. &os; generally
has the performance advantage here at the cost of wasting a little extra
- memory, but FreeBSD breaks down in the case where a large file is
+ memory, but &os; breaks down in the case where a large file is
massively shared across hundreds of processes. Linux, on the other hand,
breaks down in the case where many processes are sparsely-mapping the
same shared library and also runs non-optimally when trying to determine
@@ -530,7 +588,7 @@
even with multi-way set-associative caches (though the effect is
mitigated somewhat).</para>
- <para>FreeBSD's memory allocation code implements page coloring
+ <para>&os;'s memory allocation code implements page coloring
optimizations, which means that the memory allocation code will attempt
to locate free pages that are contiguous from the point of view of the
cache. For example, if page 16 of physical memory is assigned to page 0
@@ -554,7 +612,7 @@
modular and algorithmic approach that BSD has historically taken allows
us to study and understand the current implementation as well as
relatively cleanly replace large sections of the code. There have been a
- number of improvements to the FreeBSD VM system in the last several
+ number of improvements to the &os; VM system in the last several
years, and work is ongoing.</para>
</sect1>
@@ -566,23 +624,23 @@
<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 &os; 3.X swap
arrangements?</para>
</question>
<answer>
- <para>FreeBSD uses a fixed swap interleave which defaults to 4. This
- means that FreeBSD reserves space for four swap areas even if you
+ <para>&os; uses a fixed swap interleave which defaults to 4. This
+ means that &os; reserves space for four swap areas even if you
only have one, two, or three. Since swap is interleaved the linear
address space representing the <quote>four swap areas</quote> will be
fragmented if you do not actually have four swap areas. For
- example, if you have two swap areas A and B FreeBSD's address
+ example, if you have two swap areas A and B &os;'s address
space representation for that swap area will be interleaved in
blocks of 16 pages:</para>
<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>&os; 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
@@ -623,10 +681,16 @@
<qandaentry>
<question>
+ <para>How is the separation of clean and dirty (inactive) pages
+ related to the situation where you see low cache queue counts and
+ high active queue counts in <command>systat -vm</command>? Do the
+ systat stats roll the active and dirty pages together for the
+ active queue count?</para>
+
<para>I do not get the following:</para>
<blockquote>
- <para>It is important to note that the FreeBSD VM system attempts
+ <para>It is important to note that the &os; VM system attempts
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
@@ -635,12 +699,6 @@
cache queue counts and high active queue counts when doing a
<command>systat -vm</command> command.</para>
</blockquote>
-
- <para>How is the separation of clean and dirty (inactive) pages
- related to the situation where you see low cache queue counts and
- high active queue counts in <command>systat -vm</command>? Do the
- systat stats roll the active and dirty pages together for the
- active queue count?</para>
</question>
<answer>
@@ -649,7 +707,7 @@
separate the pages but the reality is that if we are not in a
memory crunch, we do not really have to.</para>
- <para>What this means is that FreeBSD will not try very hard to
+ <para>What this means is that &os; will not try very hard to
separate out dirty pages (inactive queue) from clean pages (cache
queue) when the system is not being stressed, nor will it try to
deactivate pages (active queue -> inactive queue) when the system
@@ -663,14 +721,14 @@
would not some of the page faults be data page faults (COW from
executable file to private page)? I.e., I would expect the page
faults to be some zero-fill and some program data. Or are you
- implying that FreeBSD does do pre-COW for the program data?</para>
+ implying that &os; does do pre-COW for the program data?</para>
</question>
<answer>
<para>A COW fault can be either zero-fill or program-data. The
mechanism is the same either way because the backing program-data
is almost certainly already in the cache. I am indeed lumping the
- two together. FreeBSD does not pre-COW program data or zero-fill,
+ two together. &os; does not pre-COW program data or zero-fill,
but it <emphasis>does</emphasis> pre-map pages that exist in its
cache.</para>
</answer>
@@ -685,7 +743,7 @@
McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of
operation/reaction would require scanning the mappings?</para>
- <para>How does Linux do in the case where FreeBSD breaks down
+ <para>How does Linux do in the case where &os; breaks down
(sharing a large file mapping over many processes)?</para>
</question>
@@ -717,7 +775,7 @@
index into the page table for each of those 50 processes even if
only 10 of them have actually mapped the page. So Linux is
trading off the simplicity of its design against performance.
- Many VM algorithms which are O(1) or (small N) under FreeBSD wind
+ Many VM algorithms which are O(1) or (small N) under &os; wind
up being O(N), O(N^2), or worse under Linux. Since the pte's
representing a particular page in an object tend to be at the same
offset in all the page tables they are mapped in, reducing the
@@ -725,12 +783,12 @@
will often avoid blowing away the L1 cache line for that offset,
which can lead to better performance.</para>
- <para>FreeBSD has added complexity (the <literal>pv_entry</literal>
+ <para>&os; has added complexity (the <literal>pv_entry</literal>
scheme) in order to increase performance (to limit page table
accesses to <emphasis>only</emphasis> those pte's that need to be
modified).</para>
- <para>But FreeBSD has a scaling problem that Linux does not in that
+ <para>But &os; has a scaling problem that Linux does not in that
there are a limited number of <literal>pv_entry</literal>
structures and this causes problems when you have massive sharing
of data. In this case you may run out of
@@ -744,10 +802,10 @@
<literal>pv_entry</literal> scheme: Linux uses
<quote>permanent</quote> page tables that are not throw away, but
does not need a <literal>pv_entry</literal> for each potentially
- mapped pte. FreeBSD uses <quote>throw away</quote> page tables but
+ mapped pte. &os; uses <quote>throw away</quote> page tables but
adds in a <literal>pv_entry</literal> structure for each
actually-mapped pte. I think memory utilization winds up being
- about the same, giving FreeBSD an algorithmic advantage with its
+ about the same, giving &os; an algorithmic advantage with its
ability to throw away page tables at will with very low
overhead.</para>
</answer>
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml#4 (text+ko) ====
@@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
- $FreeBSD: doc/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml,v 1.87 2009/11/18 20:09:55 bcr Exp $
+ $FreeBSD: doc/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml,v 1.88 2010/06/18 09:47:34 jkois Exp $
-->
<appendix id="bibliography">
@@ -163,10 +163,11 @@
<itemizedlist>
<listitem>
- <para><ulink url="http://www.AbsoluteBSD.com/">Absolute
- BSD: The Ultimate Guide to FreeBSD</ulink>, published by
- <ulink url="http://www.nostarch.com/">No Starch Press</ulink>, 2002.
- ISBN: 1886411743</para>
+ <para><ulink url="http://www.absoluteFreeBSD.com/">Absolute
+ FreeBSD, 2nd Edition: The Complete Guide to FreeBSD</ulink>,
+ published by <ulink
+ url="http://www.nostarch.com/">No Starch Press</ulink>, 2007.
+ ISBN: 978-1-59327-151-0</para>
</listitem>
<listitem>
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml#14 (text+ko) ====
@@ -1,6 +1,6 @@
<!--
The FreeBSD Documentation Project
- $FreeBSD: doc/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml,v 1.95 2010/04/30 16:11:49 rene Exp $
+ $FreeBSD: doc/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml,v 1.96 2010/06/17 18:11:37 blackend Exp $
-->
<chapter id="desktop">
@@ -181,11 +181,11 @@
<screen>&prompt.root; <userinput>pkg_add -r firefox</userinput></screen>
- <para>This will install <application>Firefox</application> 2.X,
- if you want to run <application>Firefox</application> 3.X,
+ <para>This will install <application>Firefox</application> 3.6,
+ if you want to run <application>Firefox</application> 3.5,
use instead:</para>
- <screen>&prompt.root; <userinput>pkg_add -r firefox3</userinput></screen>
+ <screen>&prompt.root; <userinput>pkg_add -r firefox35</userinput></screen>
<para>You can also use the Ports Collection if you
prefer to compile from source code:</para>
@@ -193,9 +193,9 @@
<screen>&prompt.root; <userinput>cd /usr/ports/www/firefox</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>
- <para>For <application>Firefox</application> 3.X, in the
+ <para>For <application>Firefox</application> 3.5, in the
previous command replace <literal>firefox</literal> with
- <literal>firefox3</literal>.</para>
+ <literal>firefox35</literal>.</para>
</sect2>
<sect2 id="moz-java-plugin">
@@ -204,6 +204,9 @@
<note>
<para>In this section and in the next one, we assume you have
already installed <application>Firefox</application>.</para>
+
+ <para>Currently, the &java; plugin does not work with
+ <application>Firefox</application> 3.6.</para>
</note>
<para>The &os; Foundation has a license with Sun Microsystems to
@@ -229,16 +232,22 @@
plugin should be listed there now. If it is not, each user
will have to run the following command:</para>
- <screen>&prompt.user; <userinput>ln -s /usr/local/diablo-jre1.6.0/plugin/i386/ns7/libjavaplugin_oji.so \
+ <screen>&prompt.user; <userinput>ln -s /usr/local/diablo-jre1.6.0/plugin/<replaceable>i386</replaceable>/ns7/libjavaplugin_oji.so \
$HOME/.mozilla/plugins/</userinput></screen>
<para>or, if you installed the <application>Diablo
&jdk;</application> package:</para>
- <screen>&prompt.user; <userinput>ln -s /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so \
+ <screen>&prompt.user; <userinput>ln -s /usr/local/diablo-jdk1.6.0/jre/plugin/<replaceable>i386</replaceable>/ns7/libjavaplugin_oji.so \
$HOME/.mozilla/plugins/</userinput></screen>
<para>Then relaunch your browser.</para>
+
+ <note>
+ <para>The commands above assume you are running the
+ &arch.i386; architecture, &arch.amd64; packages are also
+ available.</para>
+ </note>
</sect2>
<sect2 id="moz-flash-plugin">
==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml#9 (text+ko) ====
@@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
- $FreeBSD: doc/en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml,v 1.23 2010/02/02 20:06:34 manolis Exp $
+ $FreeBSD: doc/en_US.ISO8859-1/books/handbook/virtualization/chapter.sgml,v 1.24 2010/06/18 17:37:31 jkois Exp $
-->
<chapter id="virtualization">
@@ -273,6 +273,13 @@
</sect3>
</sect2>
+<!--
+Deactive/hide this section as the instruction in there do NOT work anyore:
+- FreeBSD 7.0 has reached its EOL a long time ago.
+- The needed files from www.fsmware.com are not available anymore, as the
+ server is dead. So it is impossible to follow the instructions in here.
+
+jkois at FreeBSD.org, 2010-06-18
<sect2 id="virtualization-guest-xen">
<sect2info>
@@ -283,7 +290,7 @@
<contrib>Contributed by </contrib>
</author>
</authorgroup>
- <!-- Mar/Apr 2007 -->
+
</sect2info>
<title>&os; with &xen; on Linux</title>
@@ -361,7 +368,7 @@
<screen>&prompt.root; <userinput>xm list</userinput>
Name ID Mem VCPUs State Time(s)
-Domain-0 0 256 1 r----- 54452.9</screen>
+Domain-0 0 256 1 r––––– 54452.9</screen>
</step>
</procedure>
</sect3>
@@ -412,7 +419,7 @@
<screen>&prompt.root; <userinput>objcopy kernel-current -R __xen_guest</userinput>
&prompt.root; <userinput>perl -e 'print "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xC0000000\x00"' > tmp</userinput>
-&prompt.root; <userinput>objcopy kernel-current --add-section __xen_guest=tmp</userinput></screen>
+&prompt.root; <userinput>objcopy kernel-current ––add-section __xen_guest=tmp</userinput></screen>
<screen>&prompt.root; <userinput>objdump -j __xen_guest -s kernel-current</userinput>
@@ -567,7 +574,7 @@
</sect3>
</sect2>
-
+-->
<sect2 id="virtualization-guest-virtualpc">
<title>Virtual PC on &windows;</title>
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#33 (text+ko) ====
@@ -1,7 +1,7 @@
<!--
The FreeBSD Dutch Documentation Project
- $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml,v 1.20 2010/01/12 20:22:04 rene Exp $
+ $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml,v 1.21 2010/06/13 11:46:05 rene Exp $
%SOURCE% en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
%SRCID% 1.247
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml#49 (text+ko) ====
@@ -1,7 +1,7 @@
<!--
The FreeBSD Dutch Documentation Project
- $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.37 2010/05/30 08:03:31 remko Exp $
+ $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.38 2010/06/13 11:46:05 rene Exp $
Vertaald door: Siebrand Mazeland / Rene Ladan
%SOURCE% en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml#30 (text+ko) ====
@@ -1,7 +1,7 @@
<!--
The FreeBSD Dutch Documentation Project
- $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml,v 1.24 2010/05/16 00:58:00 rene Exp $
+ $FreeBSD: doc/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml,v 1.25 2010/06/13 11:46:05 rene Exp $
%SOURCE% en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
%SRCID% 1.122
==== //depot/projects/docproj_nl/share/sgml/mirrors.xml#19 (text+ko) ====
@@ -2,7 +2,7 @@
<mirrors>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
- $FreeBSD: doc/share/sgml/mirrors.xml,v 1.110 2010/05/31 05:44:35 joerg Exp $
+ $FreeBSD: doc/share/sgml/mirrors.xml,v 1.111 2010/06/17 12:49:57 jkois Exp $
</cvs:keyword>
</cvs:keywords>
@@ -914,6 +914,7 @@
<entry id="mirrors-ie">
<country>Ireland</country>
+<!--
<host type="www">
<name>www.ie.FreeBSD.org</name>
<url proto="http">http://www.ie.FreeBSD.org/</url>
@@ -923,7 +924,7 @@
<name>www2.ie.FreeBSD.org</name>
<url proto="http">http://www2.ie.FreeBSD.org/</url>
</host>
-
+-->
<host type="ftp">
<name>ftp.ie.FreeBSD.org</name>
<url proto="ftp">ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/</url>
==== //depot/projects/docproj_nl/www/en/gnome/docs/faq2.sgml#6 (text+ko) ====
@@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
-<!ENTITY date "$FreeBSD: www/en/gnome/docs/faq2.sgml,v 1.143 2009/06/16 20:02:42 remko Exp $">
+<!ENTITY date "$FreeBSD: www/en/gnome/docs/faq2.sgml,v 1.144 2010/06/16 21:34:19 kwm Exp $">
<!ENTITY title "FreeBSD GNOME Project: GNOME &gnomever; FAQ">
<!ENTITY email "freebsd-gnome">
<!ENTITY % navinclude.gnome "INCLUDE">
@@ -146,8 +146,8 @@
<pre>
# /usr/local/etc/rc.d/dbus start
-# /usr/local/etc/rc.d/avahi-daemon.sh start
-# /usr/local/etc/rc.d/avahi-dnsconfd.sh start
+# /usr/local/etc/rc.d/avahi-daemon start
+# /usr/local/etc/rc.d/avahi-dnsconfd start
# /usr/local/etc/rc.d/hald start
# /usr/local/etc/rc.d/gdm start
</pre>
==== //depot/projects/docproj_nl/www/en/platforms/ppc.sgml#5 (text+ko) ====
@@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
-<!ENTITY date "$FreeBSD: www/en/platforms/ppc.sgml,v 1.25 2010/05/29 08:44:35 jkois Exp $">
+<!ENTITY date "$FreeBSD: www/en/platforms/ppc.sgml,v 1.26 2010/06/13 13:33:14 ryusuke Exp $">
<!ENTITY title "FreeBSD/ppc Project">
<!ENTITY email 'freebsd-ppc'>
<!ENTITY % navinclude.developers "INCLUDE">
@@ -230,7 +230,7 @@
<li><a href="http://developer.apple.com/technotes/tn/tn2001.html">
"TN2001: Running Files from a Hard Drive in Open Firmware"</a></li>
- <li><a href="http://sourceware.cygnus.com/psim/">psim</a> - A PowerPC
+ <li><a href="http://sourceware.org/psim/">psim</a> - A PowerPC
simulator, available as a FreeBSD port at
<a href="http://www.freshports.org/?package=psim-freebsd">
emulators/psim-freebsd</a></li>
==== //depot/projects/docproj_nl/www/nl/where.sgml#20 (text+ko) ====
@@ -1,5 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
-<!ENTITY date "$FreeBSD: www/nl/where.sgml,v 1.7 2010/02/28 12:40:30 rene Exp $">
+<!ENTITY date "$FreeBSD: www/nl/where.sgml,v 1.8 2010/06/13 11:53:01 rene Exp $">
<!ENTITY title "&os; verkrijgen">
<!ENTITY % navinclude.download "INCLUDE">
<!ENTITY url.rel "ftp://ftp.FreeBSD.org/pub/FreeBSD/releases">
==== //depot/projects/docproj_nl/www/share/sgml/commercial.consult.xml#23 (text+ko) ====
@@ -1,12 +1,12 @@
<?xml version="1.0"?>
<!DOCTYPE entries PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Commercial Gallery//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/gallery.dtd">
-<!-- $FreeBSD: www/share/sgml/commercial.consult.xml,v 1.114 2010/04/11 17:52:09 jkois Exp $ -->
+<!-- $FreeBSD: www/share/sgml/commercial.consult.xml,v 1.118 2010/06/17 21:37:40 jkois Exp $ -->
<entries>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
- $FreeBSD: www/share/sgml/commercial.consult.xml,v 1.114 2010/04/11 17:52:09 jkois Exp $
+ $FreeBSD: www/share/sgml/commercial.consult.xml,v 1.118 2010/06/17 21:37:40 jkois Exp $
</cvs:keyword>
</cvs:keywords>
@@ -137,6 +137,20 @@
</description>
</entry>
+ <entry id="blappitconsulting" category="europe">
+ <name>Blapp IT Consulting</name>
+ <url>http://www.blapp-it-consulting.ch/</url>
+ <description>
+ Located in Basel/Switzerland, Blapp-IT-Consulting provides
+ consulting services related to complex mail routing and gateway
+ solutions, SaaS, BSD Hosting, Internet servers and infrastructure,
+ programming, FreeBSD and other BSD operating systems, security
+ auditing/firewalls, system administration, etc. For more
+ information please visit our <a
+ href="http://www.blapp-it-consulting.ch/">website</a>.
+ </description>
+ </entry>
+
<entry id="BMK" category="australia">
<name>B.M.K. Industries</name>
<url>http://www.bmk.com.au</url>
@@ -496,6 +510,39 @@
</description>
</entry>
+ <entry id="GlobalTechnopolis" category="asia">
+ <name>Global Technopolis Corporation</name>
+ <url>http://globaltechnopolis.com/</url>
+ <description>
+ Located in Tokyo, Japan, The Global Technopolis Corporation provides
+ computing technology consulting services including strategy and
+ implementation proposals, administration, maintenance, hosting,
+ support, and training for <a
+ href="http://globaltechnopolis.com/services/consulting/operating-systems-and-platforms/bsd/freebsd/index.html">FreeBSD</a>.
+ Our engineers can assist your business to set up routers/gateways,
+ web servers, applications servers, database servers, backup
+ servers and so forth. Professional project management and on-time
+ delivery within budget is always our commitment to our clients.
+ For further details, please visit our <a
+ href="http://globaltechnopolis.com/">web site</a>.
+ </description>
+ </entry>
+
+ <entry id="Hypermetrica" category="europe">
+ <name>Hypermetrica</name>
+ <url>http://www.esliadmina.net</url>
+ <description>
+ IT-consulting company Hypermetrica provides IT consulting and
+ professional system administration services. We develop
+ high-available environments, web and network services for small
+ and medium-sized businesses based on FreeBSD and other UNIX
+ operating systems. Our office is located in Moscow, Russia.
+ Contact us for consulting via <a
+ href="mailto:info at hypermetrica.ru">email</a> or visit our <a
+ href="http://www.esliadmina.net">website</a>.
+ </description>
+ </entry>
+
<entry id="InformSystem" category="asia">
<name>Inform System Inc.</name>
<url>http://www.inform.co.jp/</url>
@@ -540,6 +587,20 @@
</description>
</entry>
+ <entry id="ITSchulungen" category="europe">
+ <name>IT-schulungen.com</name>
+ <url>http://www.it-schulungen.com</url>
+ <description>
+ Located in Germany, IT-Schulungen.com is a portal for IT-Trainings
+ (both individual workshops and public seminars) and offers
+ training and consulting for different Open Source systems including <a
+ href="http://www.it-schulungen.com/seminare/serversysteme/freebsd/index.html">FreeBSD</a>.
+ For further information please call 01805 120 222 (from within
+ Germany) or visit our <a
+ href="http://www.it-schulungen.com">website</a>.
+ </description>
+ </entry>
+
<entry id="ITSecurity" category="namerica">
<name>It Security Services</name>
<url>http://www.itsecuritymn.com</url>
==== //depot/projects/docproj_nl/www/share/sgml/news.dtd#2 (text+ko) ====
@@ -1,7 +1,9 @@
-<!-- $FreeBSD: www/share/sgml/news.dtd,v 1.2 2006/08/21 18:27:42 hrs Exp $ -->
+<!-- $FreeBSD: www/share/sgml/news.dtd,v 1.3 2010/06/18 16:47:01 danger Exp $ -->
<!ENTITY % xml.features "INCLUDE">
<!ENTITY % sgml.features "IGNORE">
+<!ENTITY lists 'http://lists.freebsd.org/pipermail'>
+<!ENTITY lists.stable '&lists;/freebsd-stable'>
<!ELEMENT news (cvs:keywords?, year)+>
==== //depot/projects/docproj_nl/www/share/sgml/news.xml#82 (text+ko) ====
@@ -25,7 +25,7 @@
<news>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
- $FreeBSD: www/share/sgml/news.xml,v 1.323 2010/06/11 11:19:47 ashish Exp $
+ $FreeBSD: www/share/sgml/news.xml,v 1.324 2010/06/18 16:47:01 danger Exp $
</cvs:keyword>
</cvs:keywords>
@@ -36,6 +36,22 @@
<name>6</name>
<day>
+ <name>18</name>
+
+ <event>
+ <title>&os; 8.1-RC1 Available</title>
+
+ <p>The first Release Candidate build for the &os;-8.1
+ release cycle is now available. ISO images for Tier-1
+ architectures can be downloaded from most of the <a
+ href="&url.doc.base-en;/books/handbook/mirrors-ftp.html">&os;
+ mirror sites</a>. Please see the official <a
+ href="&lists.stable;/2010-June/057320.html">announcement</a>
+ for further details about this release.</p>
+ </event>
+ </day>
+
+ <day>
<name>10</name>
<event>
@@ -80,7 +96,7 @@
<p>The first of the test builds for the &os;-8.1
release cycle is now available. ISO images for Tier-1
architectures are now <a
- href="http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/057040.html">available</a>
+ href="&lists.stable;/2010-May/057040.html">available</a>
on most of the <a
href="&url.doc.base-en;/books/handbook/mirrors-ftp.html">&os;
mirror sites</a>.</p>
@@ -273,7 +289,7 @@
<p>The second Release Candidate build for the &os;-7.3
release cycle is now available. ISO images for Tier-1
architectures are now <a
>>> TRUNCATED FOR MAIL (1000 lines) <<<
More information about the p4-projects
mailing list