MFen 1.13

Obtained from: The FreeBSD Russian Documentation Project

ru_RU.KOI8-R/articles/vm-design/article.sgml

@@ -2,14 +2,20 @@
      The FreeBSD Russian Documentation Project
 
      $FreeBSD$
-     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/vm-design/article.sgml,v 1.3 2001/07/21 14:26:19 phantom Exp $
+     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/vm-design/article.sgml,v 1.5 2004/02/01 22:11:06 maxim Exp $
 
-     Original revision: 1.4
+     Original revision: 1.13
 -->
 
 <!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
 <!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
 %man;
+
+<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
+%freebsd;
+
+<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN">
+%trademarks;
 ]>
 
 <article>
@@ -29,6 +35,14 @@
       </author>
     </authorgroup>
 
+    <legalnotice id="trademarks" role="trademarks">
+      &tm-attrib.freebsd;
+      &tm-attrib.linux;
+      &tm-attrib.microsoft;
+      &tm-attrib.opengroup;
+      &tm-attrib.general;
+    </legalnotice>
+
 <!--
     <para>Перевод на русский язык: Андрей Захватов
       (<email>andy@FreeBSD.org</email>)</para>
@@ -39,7 +53,7 @@
         VM-систему понятным языком.  Последний год я сосредоточил усилия в
         работе над несколькими основными подсистемами ядра FreeBSD, среди
         которых подсистемы VM и подкачки были самыми интересными, а NFS
-        оказалась &lsquo;необходимой рутиной&rsquo;.  Я переписал лишь малую
+        оказалась <quote>необходимой рутиной</quote>.  Я переписал лишь малую
         часть кода.  Что касается VM, то я единственным большим обновлением,
         которое я сделал, является переделка подсистемы подкачки.  Основная
         часть моей работы заключалась в зачистке и поддержке кода, с
@@ -71,8 +85,8 @@
       проработке алгоритмов.  Внимание, уделенное архитектуре, в общем
       отражается на ясности и гибкости кода, который может быть достаточно
       легко изменен, расширен или с течением времени заменен.  Хотя некоторые
-      считают BSD &lsquo;старой&rsquo; операционной системой, те их нас, кто
+      считают BSD <quote>старой</quote> операционной системой, те их нас, кто
-      работает над ней, видят ее скорее системой со &lsquo;зрелым&rsquo; кодом
+      работает над ней, видят ее скорее системой со <quote>зрелым</quote> кодом
       с различными компонентами, которые были заменены, расширены или изменены
       современным кодом.  Он развивается, и FreeBSD остается передовой
       системой, вне зависимости от того, насколько старой может быть часть
@@ -80,17 +94,18 @@
       Самой большой ошибкой, которую может допустить программист, является
       игнорирование истории, и это именно та ошибка, которую сделали многие
       другие современные операционные системы.  Самым ярки примером здесь
-      является NT, и последствия ужасны.  Linux также в некоторой степени
+      является &windowsnt;, и последствия ужасны.  Linux также в некоторой
-      совершил эту ошибку&mdash;достаточно, чтобы мы, люди BSD, по крайней
+      степени совершил эту ошибку&mdash;достаточно, чтобы мы, люди BSD, по
+      крайней
       мере по разу отпустили по этому поводу шутку.  Проблема Linux заключается
       просто в отсутствии опыта и истории для сравнения идей, проблема, которая
       легко и быстро решается сообществом Linux точно так же, как она решается
-      в сообществе BSD&mdash;постоянной работой над кодом.  Разработчики NT,
+      в сообществе BSD&mdash;постоянной работой над кодом.  Разработчики &windowsnt;,
       с другой стороны, постоянно совершают те же самые ошибки, что были
-      решены в UNIX десятки лет назад, а затем тратят годы на их устранение.
+      решены в &unix; десятки лет назад, а затем тратят годы на их устранение.
-      Снова и снова.  Есть несколько случаев &lsquo;проработка архитектуры
+      Снова и снова.  Есть несколько случаев <quote>проработка архитектуры
-      отсутствует&rsquo; и &lsquo;мы всегда правы, потому что так говорит наш
+      отсутствует</quote> и <quote>мы всегда правы, потому что так говорит наш
-      отдел продаж&rsquo;. Я плохо переношу тех, кого не учит история.</para>
+      отдел продаж</quote>. Я плохо переношу тех, кого не учит история.</para>
 
     <para>Большинство очевидной сложности архитектуры FreeBSD, особенно в
       подсистеме VM/Swap, является прямым следствием того, что она решает
@@ -249,7 +264,8 @@
       порожденным процессом.  В процессе возникнет ситуация копирования при
       записи и страница скопируется в C2.  Исходная страница в B теперь
       полностью скрыта, так как и C1, и C2 имеют копии, а B теоретически может
-      быть уничтожена, если она не представляет собой 'реального' файла).
+      быть уничтожена, если она не представляет собой <quote>реального</quote>
+      файла).
       Однако такую оптимизацию не так уж просто осуществить, потому что она
       делается на уровне мелких единиц.  Во FreeBSD такая оптимизация не
       выполняется.  Теперь положим (а это часто случается), что порожденный
@@ -346,15 +362,16 @@
       VM, только когда это действительно нужно.  Однако структура управления
       подкачкой исторически имела некоторые проблемы.</para>
 
-    <para>Во FreeBSD 3.x в структуре управления областью подкачки
+    <para>Во FreeBSD 3.X в структуре управления областью подкачки
       предварительно выделяется массив, который представляет целый объект,
       требующий хранения в области подкачки&mdash;даже если только несколько
       страниц этого объекта хранятся в области подкачки.  Это создает проблему
       фрагментации памяти ядра в случае, когда в память отображаются большие
       объекты или когда ветвятся процессы, занимающие большой объем памяти при
       работе (RSS).  Также для отслеживания памяти подкачки в памяти ядра
-      поддерживается &lsquo;список дыр&rsquo;, и он также несколько
+      поддерживается <quote>список дыр</quote>, и он также несколько
-      фрагментирован.  Так как 'список дыр' является последовательным списком,
+      фрагментирован.  Так как <quote>список дыр</quote> является
+      последовательным списком,
       то производительность при распределении и высвобождении памяти в области
       подкачки неоптимально и ее сложность зависит от количества страниц как
       O(n).  Также в процессе высвобождения памяти в области подкачки требуется
@@ -367,7 +384,7 @@
       областью подкачки при выгрузке страниц памяти в эту область.  Очевидно,
       что мест для усовершенствований предостаточно.</para>
 
-    <para>Во FreeBSD 4.x подсистема управления областью подкачки была полностью
+    <para>Во FreeBSD 4.X подсистема управления областью подкачки была полностью
       переписана мною.  При этом структуры управления областью подкачки
       распределяются при помощи хэш-таблицы, а не через линейный массив, что
       дает им фиксированный размер при распределении и работу с гораздо
@@ -385,7 +402,8 @@
       избежания потенциальных блокировок.  Наконец, для уменьшения фрагментации
       дерево может распределять большой последовательный кусок за раз,
       пропуская меньшие фрагментированные области.  Я не сделал последний шаг
-      к заведению 'указателя на распределение', который будет передвигаться
+      к заведению <quote>указателя на распределение</quote>, который будет
+      передвигаться
       по участку области подкачки при выделении памяти для обеспечения в
       будущем распределения последовательных участков, или по крайней мере
       местоположения ссылки, но я убежден, что это может быть сделано.</para>
@@ -457,7 +475,7 @@
       страницы перемещаются из неактивной очереди в очередь кэша.  В этот
       момент страницы в очереди кэша могут быть повторно активизированы VM со
       сравнительно малыми накладными расходами.  Однако страницы в очереди кэша
-      предполагается &lsquo;высвобождать немедленно&rsquo; и повторно
+      предполагается <quote>высвобождать немедленно</quote> и повторно
       использовать в LRU-порядке (меньше всего используемый), когда системе
       потребуется выделение дополнительной памяти.</para>
 
@@ -618,7 +636,7 @@
 	<question>
 	  <para>Что это за &ldquo;алгоритм чередования&rdquo;, который вы
             упоминали в списке недостатков подсистемы управления разделом
-            подкачки во FreeBSD 3.x?</para>
+            подкачки во FreeBSD 3.X?</para>
 	</question>
 
 	<answer>
@@ -627,7 +645,7 @@
             резервирует пространство для четырех областей подкачки, даже если
             у вас имеется всего лишь одна, две или три области.  Так как в
             области подкачки имеется чередование, то линейное адресное
-            пространство, представляющее &lsquo;четыре области подкачки&rsquo;,
+            пространство, представляющее <quote>четыре области подкачки</quote>,
             будет фрагментироваться, если у вас нет на самом деле четырех
             областей подкачки.  Например, если у вас две области A и B, то
             представление адресного пространства для этой области подкачки во
@@ -636,15 +654,15 @@
 
 	  <literallayout>A B C D A B C D A B C D A B C D</literallayout>
 
-	  <para>FreeBSD 3.x использует &lsquo;последовательный список свободных
+	  <para>FreeBSD 3.X использует <quote>последовательный список свободных
-            областей&rsquo; для управления свободными областями в разделе
+            областей</quote> для управления свободными областями в разделе
             подкачки.  Идея состоит в том, что большие последовательные блоки
             свободного пространства могут быть представлены при помощи узла
             односвязного списка (<filename>kern/subr_rlist.c</filename>).  Но
             из-за фрагментации последовательный список сам становится
             фрагментированным.  В примере выше полностью неиспользуемое
-            пространство в A и B будет показано как &lsquo;свободное&rsquo;,
+            пространство в A и B будет показано как <quote>свободное</quote>,
-            а C и D как &lsquo;полностью занятое&rsquo;.  Каждой
+            а C и D как <quote>полностью занятое</quote>.  Каждой
             последовательности A-B требуется для учета узел списка, потому что
             C и D являются дырами, так что узел списка не может быть связан
             со следующей последовательностью A-B.</para>
@@ -657,17 +675,17 @@
             чем пытаться выдумывать сложности в другом месте.</para>
 
 	  <para>Фрагментация вызывает другие проблемы.  Являясь
-            последовательным списком в 3.x и имея такое огромную фрагментацию,
+            последовательным списком в 3.X и имея такое огромную фрагментацию,
             выделение и освобождение в области подкачки становится алгоритмом
             сложности O(N), а не O(1).  Вместе с другими факторами (частое
             обращение к области подкачки) вы получаете сложность уровней O(N^2)
-            и O(N^3), что плохо.  В системе 3.x также может потребоваться
+            и O(N^3), что плохо.  В системе 3.X также может потребоваться
             выделение KVM во время работы с областью подкачки для создания
             нового узла списка, что в условии нехватки памяти может привести к
             блокировке, если система попытается сбросить страницы в область
             подкачки.</para>
 
-	  <para>В 4.x мы не используем последовательный список.  Вместо этого
+	  <para>В 4.X мы не используем последовательный список.  Вместо этого
             мы используем базисное дерево и битовые карты блоков области
             подкачки, а не ограниченный список узлов.  Мы принимаем
             предварительное выделение всех битовых карт, требуемых для всей
@@ -812,10 +830,10 @@
 
 	  <para>Что касается использования памяти под таблицу страниц против
             схемы с <literal>pv_entry</literal>: Linux использует
-	    &lsquo;постоянные&rsquo; таблицы страниц, которые не сбрасываются,
+	    <quote>постоянные</quote> таблицы страниц, которые не сбрасываются,
             но ему не нужны <literal>pv_entry</literal> для каждого
             потенциально отображаемого pte.  FreeBSD использует
-            &lsquo;сбрасываемые&rsquo; таблицы страниц, но для каждого
+            <quote>сбрасываемые</quote> таблицы страниц, но для каждого
             реально отображаемого pte добавляется структура
             <literal>pv_entry</literal>.  Я думаю, что использование памяти
             будет примерно одинакова, тем более что у FreeBSD есть
@@ -842,7 +860,7 @@
             прочтенные по смещению 0!</para>
 
 	  <para>Я очень сильно все упрощаю.  То, что я только что описал,
-            называется &lsquo;напрямую отображаемым&rsquo; аппаратным кэшем
+            называется <quote>напрямую отображаемым</quote> аппаратным кэшем
             памяти.  Большинство современных кэшей являются так называемыми
             2-сторонними множественными ассоциативными или 4-сторонними
             множественными ассоциативными кэшами.  Множественная
@@ -876,7 +894,7 @@
             принимать во внимание переключение контекстов процессов, что очень
             важно.</para>
 
-	  <para>Но в мире UNIX вы работаете с виртуальными адресными
+	  <para>Но в мире &unix; вы работаете с виртуальными адресными
             пространствами, а не с физическими.  Любая программа, вами
             написанная, имеет дело с виртуальным адресным пространством, ей
             предоставленным.  Реальные <emphasis>физические</emphasis>
@@ -903,8 +921,8 @@
             адресного пространства будут такими же, как если бы программа
             работала непосредственно в физическом адресном пространстве.</para>
 
-	  <para>Заметьте, что я сказал &lsquo;примерно&rsquo; подходящие, а не
+	  <para>Заметьте, что я сказал <quote>примерно</quote> подходящие, а не
-            просто &lsquo;последовательные&rsquo;.  С точки зрения напрямую
+            просто <quote>последовательные</quote>.  С точки зрения напрямую
             отображаемого кэша в 128К, физический адрес 0 одинаков с физическим
             адресом 128К.  Так что две граничащие страницы в вашем виртуальном
             адресном пространстве могут располагаться по смещению 128К и 132К