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

MFen 1.13

Browse source 
Obtained from: The FreeBSD Russian Documentation Project
This commit is contained in:
Andrey Zakhvatov 2004-02-21 06:13:48 +00:00
parent 511f6edaaf
commit 1f4effc8a5
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=20110
1 changed files with 52 additions and 34 deletions

86
ru_RU.KOI8-R/articles/vm-design/article.sgml
View file

@ -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; операционной системой, те их нас, кто
работает над ней, видят ее скорее системой со &lsquo;зрелым&rsquo; кодом
считают BSD <quote>старой</quote> операционной системой, те их нас, кто
работает над ней, видят ее скорее системой со <quote>зрелым</quote> кодом
с различными компонентами, которые были заменены, расширены или изменены
современным кодом. Он развивается, и FreeBSD остается передовой
системой, вне зависимости от того, насколько старой может быть часть
@ -80,17 +94,18 @@
Самой большой ошибкой, которую может допустить программист, является
игнорирование истории, и это именно та ошибка, которую сделали многие
другие современные операционные системы. Самым ярки примером здесь
является NT, и последствия ужасны. Linux также в некоторой степени
совершил эту ошибку&mdash;достаточно, чтобы мы, люди BSD, по крайней
является &windowsnt;, и последствия ужасны. Linux также в некоторой
степени совершил эту ошибку&mdash;достаточно, чтобы мы, люди BSD, по
крайней
мере по разу отпустили по этому поводу шутку. Проблема Linux заключается
просто в отсутствии опыта и истории для сравнения идей, проблема, которая
легко и быстро решается сообществом Linux точно так же, как она решается
в сообществе BSD&mdash;постоянной работой над кодом. Разработчики NT,
в сообществе BSD&mdash;постоянной работой над кодом. Разработчики &windowsnt;,
с другой стороны, постоянно совершают те же самые ошибки, что были
решены в UNIX десятки лет назад, а затем тратят годы на их устранение.
Снова и снова. Есть несколько случаев &lsquo;проработка архитектуры
отсутствует&rsquo; и &lsquo;мы всегда правы, потому что так говорит наш
отдел продаж&rsquo;. Я плохо переношу тех, кого не учит история.</para>
решены в &unix; десятки лет назад, а затем тратят годы на их устранение.
Снова и снова. Есть несколько случаев <quote>проработка архитектуры
отсутствует</quote> и <quote>мы всегда правы, потому что так говорит наш
отдел продаж</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;последовательный список свободных
областей&rsquo; для управления свободными областями в разделе
<para>FreeBSD 3.X использует <quote>последовательный список свободных
областей</quote> для управления свободными областями в разделе
подкачки. Идея состоит в том, что большие последовательные блоки
свободного пространства могут быть представлены при помощи узла
односвязного списка (<filename>kern/subr_rlist.c</filename>). Но
из-за фрагментации последовательный список сам становится
фрагментированным. В примере выше полностью неиспользуемое
пространство в A и B будет показано как &lsquo;свободное&rsquo;,
а C и D как &lsquo;полностью занятое&rsquo;. Каждой
пространство в A и B будет показано как <quote>свободное</quote>,
а 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; подходящие, а не
просто &lsquo;последовательные&rsquo;. С точки зрения напрямую
<para>Заметьте, что я сказал <quote>примерно</quote> подходящие, а не
просто <quote>последовательные</quote>. С точки зрения напрямую
отображаемого кэша в 128К, физический адрес 0 одинаков с физическим
адресом 128К. Так что две граничащие страницы в вашем виртуальном
адресном пространстве могут располагаться по смещению 128К и 132К