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

MFen: articles/cups/article.sgml 1.3 --> 1.5

Browse source 
articles/vm-design/article.sgml  1.15 -->  1.18
This commit is contained in:
Taras Korenko 2010-08-30 16:58:06 +00:00
parent 5c2160b991
commit fc89606bd2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=36342
2 changed files with 178 additions and 110 deletions
ru_RU.KOI8-R/articles
cups
article.sgml
vm-design
article.sgml

17
ru_RU.KOI8-R/articles/cups/article.sgml
View file

@ -3,7 +3,7 @@
$FreeBSD$
Original revision: 1.3
Original revision: 1.5
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@ -108,7 +108,20 @@ Translation: Taras Korenko,
<programlisting>[system=10]
add path 'unlpt*' mode 0660 group cups
add path 'ulpt*' mode 0660 group cups
add path 'lpt*' mode 0660 group cups</programlisting>
add path 'lpt*' mode 0660 group cups
add path 'usb/<replaceable>X</replaceable>.<replaceable>Y</replaceable>.<replaceable>Z</replaceable>' mode 0660 group cups</programlisting>
<note>
<para>Замените <replaceable>X</replaceable>,
<replaceable>Y</replaceable> и <replaceable>Z</replaceable> номерами
соответствующего принтеру целевого устройства USB, отображаемого
в каталоге <filename class="directory">/dev/usb</filename>. Чтобы
найти требуемые значения, просмотрите вывод &man.dmesg.8; и найдите
связанное с вашим принтером имя специального устройства
<filename>ugen<replaceable>X</replaceable>.<replaceable>Y</replaceable></filename>,
последнее будет символической ссылкой на искомое устройство в каталоге
<filename class="directory">/dev/usb</filename>.</para>
</note>
<para>úÁÔÅÍ, ÄÏÂÁ×ØÔÅ ÓÌÅÄÕÀÝÉÅ Ä×Å ÚÁÐÉÓÉ ×
<filename>/etc/rc.conf</filename>:</para>

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

@ -4,7 +4,7 @@
$FreeBSD$
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/vm-design/article.sgml,v 1.7 2005/06/11 13:41:40 gad Exp $
Original revision: 1.15
Original revision: 1.18
-->
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@ -14,7 +14,7 @@
<article lang="ru">
<articleinfo>
<title>Элементы архитектуры системы виртуальной памяти во FreeBSD</title>
<title>Элементы архитектуры системы виртуальной памяти во &os;</title>
<authorgroup>
<author>
@ -45,7 +45,7 @@
<abstract>
<para>Название статьи говорит лишь о том, что я попытаюсь описать в целом
VM-систему понятным языком. Последний год я сосредоточил усилия в
работе над несколькими основными подсистемами ядра FreeBSD, среди
работе над несколькими основными подсистемами ядра &os;, среди
которых подсистемы VM и подкачки были самыми интересными, а NFS
оказалась <quote>необходимой рутиной</quote>. Я переписал лишь малую
часть кода. Что касается VM, то я единственным большим обновлением,
@ -64,7 +64,7 @@
<para>Первоначально эта статья была опубликована в номере <ulink
url="http://www.daemonnews.org/">DaemonNews</ulink> за январь 2000
года. Эта версия статьи может включать добавления, касающиеся
изменений в реализации VM во FreeBSD от Мэтта и других авторов.</para>
изменений в реализации VM во &os; от Мэтта и других авторов.</para>
</legalnotice>
</articleinfo>
@ -82,7 +82,7 @@
считают BSD <quote>старой</quote> операционной системой, те их нас, кто
работает над ней, видят ее скорее системой со <quote>зрелым</quote> кодом
с различными компонентами, которые были заменены, расширены или изменены
современным кодом. Он развивается, и FreeBSD остается передовой
современным кодом. Он развивается, и &os; остается передовой
системой, вне зависимости от того, насколько старой может быть часть
кода. Это важное отличие, которое, к сожалению, не всеми понимается.
Самой большой ошибкой, которую может допустить программист, является
@ -101,37 +101,48 @@
отсутствует</quote> и <quote>мы всегда правы, потому что так говорит наш
отдел продаж</quote>. Я плохо переношу тех, кого не учит история.</para>
<para>Большинство очевидной сложности архитектуры FreeBSD, особенно в
<para>Большинство очевидной сложности архитектуры &os;, особенно в
подсистеме VM/Swap, является прямым следствием того, что она решает
серьезные проблемы с производительностью, которые проявляются при
различных условиях. Эти проблемы вызваны не плохой проработкой
алгоритмов, а возникают из окружающих факторов. В любом прямом сравнении
между платформами эти проблемы проявляются, когда системные ресурсы
начинают истощаться. Так как я описываю подсистему VM/Swap во FreeBSD,
то читатель должен всегда иметь в виду два обстоятельства. Во-первых,
самым важным аспектом при проектировании производительности является то,
что называется &ldquo;оптимизацией критического маршрута&rdquo;. Часто
случается, что оптимизация производительности дает прирост объема кода
ради того, чтобы критический маршрут работал быстрее. Во-вторых,
четкость общей архитектуры оказывается лучше сильно оптимизированной
архитектуры с течением времени. Когда как обобщенная архитектура
может быть медленнее, чем оптимизированная архитектура, при первой
реализации, при обобщенной архитектуре легче подстраиваться под
изменяющиеся условия и чрезмерно оптимизированная архитектура оказывается
непригодной. Любой код, который должен выжить и поддаваться поддержке
начинают истощаться. Так как я описываю подсистему VM/Swap во &os;,
то читатель должен всегда иметь в виду два обстоятельства:</para>
<orderedlist>
<listitem>
<para>Самым важным аспектом при проектировании производительности
является то, что называется &ldquo;оптимизацией критического
маршрута&rdquo;. Часто случается, что оптимизация производительности
дает прирост объема кода ради того, чтобы критический маршрут
работал быстрее.</para>
</listitem>
<listitem>
<para>Четкость общей архитектуры оказывается лучше сильно
оптимизированной архитектуры с течением времени. Когда как
обобщенная архитектура может быть медленнее, чем оптимизированная
архитектура, при первой реализации, при обобщенной архитектуре легче
подстраиваться под изменяющиеся условия и чрезмерно оптимизированная
архитектура оказывается непригодной.</para>
</listitem>
</orderedlist>
<para>Любой код, который должен выжить и поддаваться поддержке
годы, должен поэтому быть тщательно продуман с самого начала, даже если
это стоит потери производительности. Двадцать лет назад были те, кто
отстаивал преимущество программирования на языке ассемблера перед
программированием на языке высокого уровня, потому что первый генерировал
в десять раз более быстрый код. В наши дни ошибочность этого аргумента
очевидна&mdash;можно провести параллели с построением алгоритмов и
обобщением кода.</para>
очевидна&nbsp;&mdash;&nbsp;можно провести параллели с построением
алгоритмов и обобщением кода.</para>
</sect1>
<sect1 id="vm-objects">
<title>Объекты VM</title>
<para>Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на
<para>Лучше всего начать описание VM-системы &os; с попытки взглянуть на
нее с точки зрения пользовательского процесса. Каждый пользовательский
процесс имеет единое, принадлежащее только ему и неразрывное адресное
пространство VM, содержащее несколько типов объектов памяти. Эти объекты
@ -177,7 +188,7 @@
потомок) полагают, что их собственные изменения после разветвления будут
принадлежать только им, и не затронут родственный процесс.</para>
<para>FreeBSD управляет всем этим при помощи многоуровневой модели
<para>&os; управляет всем этим при помощи многоуровневой модели
VM-объектов. Исходный файл с двоичной программой переносится на самый
нижний уровень объектов VM. Уровень страниц, копируемых при записи,
находится выше него, и хранит те страницы, которые были скопированы из
@ -261,7 +272,7 @@
быть уничтожена, если она не представляет собой <quote>реального</quote>
файла).
Однако такую оптимизацию не так уж просто осуществить, потому что она
делается на уровне мелких единиц. Во FreeBSD такая оптимизация не
делается на уровне мелких единиц. Во &os; такая оптимизация не
выполняется. Теперь положим (а это часто случается), что порожденный
процесс выполняет вызов <function>exec()</function>. Его текущее
адресное пространство обычно заменяется новым адресным пространством,
@ -303,7 +314,7 @@
копии страницы, а исходная страница в B становится никому не доступной.
такая страница в B может быть высвобождена.</para>
<para>FreeBSD решает проблему с глубиной вложенности с помощью приема
<para>&os; решает проблему с глубиной вложенности с помощью приема
оптимизации, который называется &ldquo;All Shadowed Case&rdquo;. Этот
случай возникает, если в C1 либо C2 возникает столько случаев копирования
страниц при записи, что они полностью закрывают все страницы в B.
@ -337,7 +348,7 @@
то, что вы можете построить сравнительно сложную иерархию объектов VM,
которая несколько замедляет обработку ситуаций отсутствия страниц памяти,
и к тому же тратится память на управление структурами объектов VM.
Приемы оптимизации, применяемые во FreeBSD, позволяют снизить значимость
Приемы оптимизации, применяемые во &os;, позволяют снизить значимость
этих проблем до степени, когда их можно без особых потерь
игнорировать.</para>
</sect1>
@ -352,52 +363,94 @@
когда VM-системе нужно использовать ее повторно для других целей. В
этот момент на помощь приходит область подкачки. Область подкачки
выделяется для организации хранилища памяти, которая иначе не может быть
доступна. FreeBSD создает структуру управления подкачкой для объекта
доступна. &os; создает структуру управления подкачкой для объекта
VM, только когда это действительно нужно. Однако структура управления
подкачкой исторически имела некоторые проблемы.</para>
подкачкой исторически имела некоторые проблемы:</para>
<para>Во FreeBSD 3.X в структуре управления областью подкачки
предварительно выделяется массив, который представляет целый объект,
требующий хранения в области подкачки&mdash;даже если только несколько
страниц этого объекта хранятся в области подкачки. Это создает проблему
фрагментации памяти ядра в случае, когда в память отображаются большие
объекты или когда ветвятся процессы, занимающие большой объем памяти при
работе (RSS). Также для отслеживания памяти подкачки в памяти ядра
поддерживается <quote>список дыр</quote>, и он также несколько
фрагментирован. Так как <quote>список дыр</quote> является
последовательным списком,
то производительность при распределении и высвобождении памяти в области
подкачки неоптимально и ее сложность зависит от количества страниц как
O(n). Также в процессе высвобождения памяти в области подкачки требуется
выделение памяти в ядре, и это приводит к проблемам блокировки при
недостатке памяти. Проблема еще более обостряется из-за дыр, создаваемых
по чередующемуся алгоритму. Кроме того, список распределения блоков в
области подкачки легко оказывается фрагментированной, что приводит к
распределению непоследовательных областей. Память ядра также должна
распределяться по ходу работы для дополнительных структур по управлению
областью подкачки при выгрузке страниц памяти в эту область. Очевидно,
что мест для усовершенствований предостаточно.</para>
<itemizedlist>
<listitem>
<para>Во &os; 3.X в структуре управления областью подкачки
предварительно выделяется массив, который представляет целый объект,
требующий хранения в области подкачки&mdash;даже если только
несколько страниц этого объекта хранятся в области подкачки. Это
создает проблему фрагментации памяти ядра в случае, когда в память
отображаются большие объекты или когда ветвятся процессы, занимающие
большой объем памяти при работе (RSS).</para>
</listitem>
<para>Во FreeBSD 4.X подсистема управления областью подкачки была полностью
переписана мною. При этом структуры управления областью подкачки
распределяются при помощи хэш-таблицы, а не через линейный массив, что
дает им фиксированный размер при распределении и работу с гораздо
меньшими структурами. Вместо того, чтобы использовать однонаправленный
связный список для отслеживания выделения пространства в области
подкачки, теперь используется побитовая карта блоков области подкачки,
выполненная в основном в виде древовидной структуры с информацией о
свободном пространстве, находящейся в узлах структур. Это приводит к
тому, что выделение и высвобождение памяти в области подкачки становится
операцией сложности O(1). Все дерево также распределяется заранее для
того, чтобы избежать распределения памяти ядра во время операций с
областью подкачки при критически малом объеме свободной памяти. В конце
концов, система обращается к области подкачки при нехватке памяти, так
что мы должны избежать распределения памяти ядра в такие моменты для
избежания потенциальных блокировок. Наконец, для уменьшения фрагментации
дерево может распределять большой последовательный кусок за раз,
пропуская меньшие фрагментированные области. Я не сделал последний шаг
к заведению <quote>указателя на распределение</quote>, который будет
передвигаться
<listitem>
<para>Также для отслеживания памяти подкачки в памяти ядра
поддерживается <quote>список дыр</quote>, и он также несколько
фрагментирован. Так как <quote>список дыр</quote> является
последовательным списком, то производительность при распределении
и высвобождении памяти в области подкачки неоптимально и ее
сложность зависит от количества страниц как O(n).</para>
</listitem>
<listitem>
<para>Также в процессе высвобождения памяти в области подкачки
требуется выделение памяти в ядре, и это приводит к проблемам
блокировки при недостатке памяти.</para>
</listitem>
<listitem>
<para>Проблема еще более обостряется из-за дыр, создаваемых
по чередующемуся алгоритму.</para>
</listitem>
<listitem>
<para>Кроме того, список распределения блоков в
области подкачки легко оказывается фрагментированным, что приводит
к распределению непоследовательных областей.</para>
</listitem>
<listitem>
<para>Память ядра также должна распределяться по ходу работы
для дополнительных структур по управлению областью подкачки при
выгрузке страниц памяти в эту область.</para>
</listitem>
</itemizedlist>
<para>Очевидно, что мест для усовершенствований предостаточно.
Во &os; 4.X подсистема управления областью подкачки была полностью
переписана мною:</para>
<itemizedlist>
<listitem>
<para>Структуры управления областью подкачки распределяются при помощи
хэш-таблицы, а не через линейный массив, что дает им фиксированный
размер при распределении и работу с гораздо меньшими
структурами.</para>
</listitem>
<listitem>
<para>Вместо того, чтобы использовать однонаправленный
связный список для отслеживания выделения пространства в области
подкачки, теперь используется побитовая карта блоков области
подкачки, выполненная в основном в виде древовидной структуры
с информацией о свободном пространстве, находящейся в узлах структур.
Это приводит к тому, что выделение и высвобождение памяти в области
подкачки становится операцией сложности O(1).</para>
</listitem>
<listitem>
<para>Все дерево также распределяется заранее для
того, чтобы избежать распределения памяти ядра во время операций с
областью подкачки при критически малом объеме свободной памяти.
В конце концов, система обращается к области подкачки при нехватке
памяти, так что мы должны избежать распределения памяти ядра в такие
моменты для избежания потенциальных блокировок.</para>
</listitem>
<listitem>
<para>Для уменьшения фрагментации дерево может распределять большой
последовательный кусок за раз, пропуская меньшие фрагментированные
области.</para>
</listitem>
</itemizedlist>
<para>Я не сделал последний шаг к заведению <quote>указателя на
распределение</quote>, который будет передвигаться
по участку области подкачки при выделении памяти для обеспечения в
будущем распределения последовательных участков, или по крайней мере
местоположения ссылки, но я убежден, что это может быть сделано.</para>
@ -420,7 +473,7 @@
будет стоить нам сотни тысяч тактов работы центрального процессора и
заметное замедление работы затронутых процессов, так что мы должны
смириться со значительными издержками для того, чтобы была заведомо
выбрана правильная страница. Вот почему FreeBSD превосходит другие
выбрана правильная страница. Вот почему &os; превосходит другие
системы в производительности при нехватке ресурсов памяти.</para>
<para>Алгоритм определения свободной страницы написан на основе истории
@ -451,10 +504,10 @@
она снова нужна процессу и подгружать ее с диска.</para>
</sidebar>
<para>FreeBSD использует несколько очередей страниц для обновления выбора
<para>&os; использует несколько очередей страниц для обновления выбора
страниц для повторного использования, а также для определения того, когда
же грязные страницы должны быть сброшены в хранилище. Так как таблицы
страниц во FreeBSD являются динамическими объектами, практически ничего
страниц во &os; являются динамическими объектами, практически ничего
не стоит вырезать страницу из адресного пространства любого использующего
ее процесса. После того, как подходящая страница, на основе счетчика
использования, выбрана, именно это и выполняется. Система должна
@ -473,7 +526,7 @@
использовать в LRU-порядке (меньше всего используемый), когда системе
потребуется выделение дополнительной памяти.</para>
<para>Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и
<para>Стоит отметить, что во &os; VM-система пытается разделить чистые и
грязные страницы во избежание срочной необходимости в ненужных сбросах
грязных страниц (что отражается на пропускной способности ввода/вывода) и
не перемещает беспричинно страницы между разными очередями, когда
@ -483,9 +536,11 @@
очереди кэша мало, а счетчик активной очереди большой. При повышении
нагрузки на VM-систему она прилагает большие усилия на поддержку
различных очередей страниц в соотношениях, которые являются наиболее
эффективными. Годами ходили современные легенды, что Linux выполняет
работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не
так. На самом деле FreeBSD старается сбросить на диск неиспользуемые
эффективными.</para>
<para>Годами ходили современные легенды, что Linux выполняет
работу по предотвращению выгрузки на диск лучше, чем &os;, но это не
так. На самом деле &os; старается сбросить на диск неиспользуемые
страницы для освобождения места под дисковый кэш, когда как Linux хранит
неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов
меньше памяти. Я не знаю, остается ли это правдой на сегодняшний
@ -504,9 +559,9 @@
снова. Если бинарный файл программы отображен в память, но не отображен
в таблицу страниц, то все страницы, к которым обращалась программа,
окажутся недоступными при каждом запуске программы. Это не так уж
необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD
необходимо, если эти страницы уже присутствуют в кэше VM, так что &os;
будет пытаться восстанавливать таблицы страниц процесса из тех страниц,
что уже располагаются в VM-кэше. Однако во FreeBSD пока не выполняется
что уже располагаются в VM-кэше. Однако во &os; пока не выполняется
предварительное копирование при записи определенных страниц при выполнении
вызова exec. Например, если вы запускаете программу &man.ls.1;
одновременно с работающей <command>vmstat 1</command>, то заметите, что
@ -537,7 +592,7 @@
<title>Оптимизация таблицы страниц</title>
<para>Оптимизация таблицы страниц составляет самую содержательную часть
архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при
архитектуры VM во &os; и она проявляется при появлении нагрузки при
значительном использовании <function>mmap()</function>. Я думаю, что это
на самом деле особенность работы большинства BSD-систем, хотя я не
уверен, когда это проявилось впервые. Есть два основных подхода к
@ -546,26 +601,26 @@
любой момент с малыми накладными расходами. Второй подход состоит в том,
что каждая активная таблица страниц в системе имеет управляющую структуру
<literal>pv_entry</literal>, которая связана в структуру
<literal>vm_page</literal>. FreeBSD может просто просматривать эти
<literal>vm_page</literal>. &os; может просто просматривать эти
отображения, которые существуют, когда как в Linux должны проверяться все
таблицы страниц, которые <emphasis>могут</emphasis> содержать нужное
отображение, что в некоторых ситуация дает увеличение сложности O(n^2).
Из-за того, что FreeBSD стремится выбрать наиболее подходящую к
Из-за того, что &os; стремится выбрать наиболее подходящую к
повторному использованию или сбросу в область подкачки страницу, когда
ощущается нехватка памяти, система дает лучшую производительность при
нагрузке. Однако во FreeBSD требуется тонкая настройка ядра для
нагрузке. Однако во &os; требуется тонкая настройка ядра для
соответствия ситуациям с большим совместно используемым адресным
пространством, которые могут случиться в системе, обслуживающей сервер
телеконференций, потому что структуры <literal>pv_entry</literal> могут
оказаться исчерпанными.</para>
<para>И в Linux, и во FreeBSD требуются доработки в этой области. FreeBSD
<para>И в Linux, и во &os; требуются доработки в этой области. &os;
пытается максимизировать преимущества от потенциально редко применяемой
модели активного отображения (к примеру, не всем процессам нужно
отображать все страницы динамической библиотеки), когда как Linux
пытается упростить свои алгоритмы. FreeBSD имеет здесь общее преимущество
пытается упростить свои алгоритмы. &os; имеет здесь общее преимущество
в производительности за счет использования дополнительной памяти, но
FreeBSD выглядит хуже в случае, когда большой файл совместно используется
&os; выглядит хуже в случае, когда большой файл совместно используется
сотнями процессов. Linux, с другой стороны, выглядит хуже в случае,
когда много процессов частично используют одну и ту же динамическую
библиотеку, а также работает неоптимально при попытке определить, может
@ -592,7 +647,7 @@
и снижению производительности CPU. Это так даже с множественными
ассоциативными кэшами (хотя здесь эффект несколько сглажен).</para>
<para>Код выделения памяти во FreeBSD выполняет оптимизацию с применением
<para>Код выделения памяти во &os; выполняет оптимизацию с применением
подгонки страниц, означающую то, что код выделения памяти будет пытаться
найти свободные страницы, которые являются последовательными с точки
зрения кэша. Например, если страница 16 физической памяти назначается
@ -617,7 +672,7 @@
и алгоритмический подход, которому исторически следует BSD, позволяет нам
изучить и понять существующую реализацию, а также сравнительно легко
изменить большие блоки кода. За несколько последних лет в VM-системе
FreeBSD было сделано некоторое количество усовершенствований, и работа
&os; было сделано некоторое количество усовершенствований, и работа
над ними продолжается.</para>
</sect1>
@ -630,12 +685,12 @@
<question>
<para>Что это за &ldquo;алгоритм чередования&rdquo;, который вы
упоминали в списке недостатков подсистемы управления разделом
подкачки во FreeBSD 3.X?</para>
подкачки во &os; 3.X?</para>
</question>
<answer>
<para>FreeBSD использует в области подкачки механизм чередования,
с индексом по умолчанию, равным четырем. Это означает, что FreeBSD
<para>&os; использует в области подкачки механизм чередования,
с индексом по умолчанию, равным четырем. Это означает, что &os;
резервирует пространство для четырех областей подкачки, даже если
у вас имеется всего лишь одна, две или три области. Так как в
области подкачки имеется чередование, то линейное адресное
@ -643,12 +698,12 @@
будет фрагментироваться, если у вас нет на самом деле четырех
областей подкачки. Например, если у вас две области A и B, то
представление адресного пространства для этой области подкачки во
FreeBSD будет организовано с чередованием блоков из 16
&os; будет организовано с чередованием блоков из 16
страниц:</para>
<literallayout>A B C D A B C D A B C D A B C D</literallayout>
<para>FreeBSD 3.X использует <quote>последовательный список свободных
<para>&os; 3.X использует <quote>последовательный список свободных
областей</quote> для управления свободными областями в разделе
подкачки. Идея состоит в том, что большие последовательные блоки
свободного пространства могут быть представлены при помощи узла
@ -693,10 +748,17 @@
<qandaentry>
<question>
<para>Как разделение чистых и грязных (неактивных) страниц связано с
ситуацией, когда вы видите маленький счетчик очереди кэша и
большой счетчик активной очереди в выдаче команды
<command>systat -vm</command>? Разве системная статистика не
считает активные и грязные страницы вместе за счетчик активной
очереди?</para>
<para>Я не понял следующее:</para>
<blockquote>
<para>Стоит отметить, что во FreeBSD VM-система пытается разделить
<para>Стоит отметить, что во &os; VM-система пытается разделить
чистые и грязные страницы во избежание срочной необходимости в
ненужных сбросах грязных страниц (что отражается на пропускной
способности ввода/вывода) и не перемещает беспричинно страницы
@ -706,13 +768,6 @@
системах значение счетчика очереди кэша мало, а счетчик активной
очереди большой.</para>
</blockquote>
<para>Как разделение чистых и грязных (неактивных) страниц связано с
ситуацией, когда вы видите маленький счетчик очереди кэша и
большой счетчик активной очереди в выдаче команды
<command>systat -vm</command>? Разве системная статистика не
считает активные и грязные страницы вместе за счетчик активной
очереди?</para>
</question>
<answer>
@ -721,7 +776,7 @@
реальность такова, что пока у нас нет проблем с памятью, нам это на
самом деле не нужно.</para>
<para>Это означает, что FreeBSD не будет очень сильно стараться над
<para>Это означает, что &os; не будет очень сильно стараться над
отделением грязных страниц (неактивная очередь) от чистых страниц
(очередь кэша), когда система не находится под нагрузкой, и не
будет деактивировать страницы (активная очередь -> неактивная
@ -737,7 +792,7 @@
(COW из выполнимого файла в приватные страницы)? То есть я
полагаю, что ошибки доступа к страницам являются частично ошибками
при заполнении нулями, а частично данных программы. Или вы
гарантируете, что FreeBSD выполняет предварительно COW для данных
гарантируете, что &os; выполняет предварительно COW для данных
программы?</para>
</question>
@ -745,7 +800,7 @@
<para>Ошибка COW может быть ошибкой при заполнении нулями или данных
программы. Механизм в любом случае один и тот же, потому что
хранилище данных программы уже в кэше. Я на самом деле не рад
ни тому, ни другому. FreeBSD не выполняет предварительное COW
ни тому, ни другому. &os; не выполняет предварительное COW
данных программы и заполнение нулями, но она
<emphasis>выполняет</emphasis> предварительно отображение страниц,
которые имеются в ее кэше.</para>
@ -762,7 +817,7 @@
действие/реакцию должно потребоваться для сканирования
отображений?</para>
<para>Что делает Linux в тех случаях, когда FreeBSD работает плохо
<para>Что делает Linux в тех случаях, когда &os; работает плохо
(совместное использование отображения файла между многими
процессами)?</para>
</question>
@ -798,7 +853,7 @@
страниц для каждого из этих 50 процессов, даже если только 10 из
них на самом деле отображают страницу. Так что Linux использует
простоту подхода за счет производительности. Многие алгоритмы VM,
которые имеют сложность O(1) или (N малое) во FreeBSD, в Linux
которые имеют сложность O(1) или (N малое) во &os;, в Linux
приобретают сложность O(N), O(N^2) или хуже. Так как pte,
представляющий конкретную страницу в объекте, скорее всего, будет
с тем же смещением во всех таблицах страниц, в которых они
@ -807,12 +862,12 @@
кэша L1 для этого смещения, что приводит к улучшению
производительности.</para>
<para>Во FreeBSD введены дополнительные сложности (схема с
<para>Во &os; введены дополнительные сложности (схема с
<literal>pv_entry</literal>) для увеличения производительности
(уменьшая количество обращений <emphasis>только</emphasis> к тем
pte, которые нужно модифицировать).</para>
<para>Но во FreeBSD имеется проблема масштабирования, которой нет в
<para>Но во &os; имеется проблема масштабирования, которой нет в
Linux, потому что имеется ограниченное число структур
<literal>pv_entry</literal>, и это приводит к возникновению проблем
при большом объеме совместно используемых данных. В этом случае
@ -826,11 +881,11 @@
схемы с <literal>pv_entry</literal>: Linux использует
<quote>постоянные</quote> таблицы страниц, которые не сбрасываются,
но ему не нужны <literal>pv_entry</literal> для каждого
потенциально отображаемого pte. FreeBSD использует
потенциально отображаемого pte. &os; использует
<quote>сбрасываемые</quote> таблицы страниц, но для каждого
реально отображаемого pte добавляется структура
<literal>pv_entry</literal>. Я думаю, что использование памяти
будет примерно одинакова, тем более что у FreeBSD есть
будет примерно одинакова, тем более что у &os; есть
алгоритмическое преимущество, заключающееся в способности
сбрасывать таблицы страниц с очень малыми накладными
расходами.</para>