diff options
Diffstat (limited to 'documentation/content/ru/articles')
| -rw-r--r-- | documentation/content/ru/articles/vm-design/_index.adoc | 49 | ||||
| -rw-r--r-- | documentation/content/ru/articles/vm-design/_index.po | 1356 |
2 files changed, 1372 insertions, 33 deletions
diff --git a/documentation/content/ru/articles/vm-design/_index.adoc b/documentation/content/ru/articles/vm-design/_index.adoc index 99af966d20..e0847dea68 100644 --- a/documentation/content/ru/articles/vm-design/_index.adoc +++ b/documentation/content/ru/articles/vm-design/_index.adoc @@ -1,9 +1,12 @@ --- -title: Элементы архитектуры системы виртуальной памяти во FreeBSD authors: - - author: Matthew Dillon + - + author: 'Matthew Dillon' email: dillon@apollo.backplane.com -trademarks: ["freebsd", "linux", "microsoft", "opengroup", "general"] +description: 'Простое и понятное описание архитектуры системы виртуальной памяти FreeBSD' +tags: ["Design", "virtual machine", "FreeBSD"] +title: 'Элементы архитектуры системы виртуальной памяти во FreeBSD' +trademarks: ["freebsd", "linux", "microsoft", "opengroup", "daemon-news", "general"] --- = Элементы архитектуры системы виртуальной памяти во FreeBSD @@ -37,10 +40,17 @@ ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] +[NOTE] +==== +Этот документ устарел, и некоторые разделы больше не соответствуют текущему состоянию системы виртуальной памяти. Он сохранён в исторических целях и может быть обновлён в будущем. +==== + [.abstract-title] Аннотация -Название статьи говорит лишь о том, что я попытаюсь описать в целом VM-систему понятным языком. Последний год я сосредоточил усилия в работе над несколькими основными подсистемами ядра FreeBSD, среди которых подсистемы VM и подкачки были самыми интересными, а NFS оказалась "необходимой рутиной". Я переписал лишь малую часть кода. Что касается VM, то я единственным большим обновлением, которое я сделал, является переделка подсистемы подкачки. Основная часть моей работы заключалась в зачистке и поддержке кода, с единственной заметной переделкой кода и без значительной переделки алгоритмов в VM-подсистеме. В основном теоретическая база работы VM-подсистемы осталась неизменной, а большинство благодарностей за современных нововведения за последние несколько лет принадлежат John Dyson и David Greenman. Не являясь историком, как Керк, я не буду пытаться связать различные возможности системы с именами, потому что обязательно ошибусь. +Matthew Dillon <dillon@apollo.backplane.com> + +Это название — просто замысловатый способ сказать, что я попытаюсь описать всю систему виртуальной памяти (VM) целиком, по возможности так, чтобы это было понятно каждому.В течение последнего года я сосредоточился на нескольких основных подсистемах ядра FreeBSD. Наиболее интересными из них стали подсистемы VM и подкачки (Swap), тогда как работа с NFS оказалась, скорее, «необходимой рутиной». Я переписал лишь небольшие части кода. В области VM моей единственной крупной переработкой стала подсистема подкачки. В основном моя работа заключалась в очистке и поддержке кода, с умеренными правками и без серьёзных изменений алгоритмов в подсистеме VM. Теоретическая основа VM-подсистемы осталась неизменной, и львиная доля заслуг в её модернизации за последние годы принадлежит Джону Дайсону и Дэвиду Гринману. Я не историк, в отличие от Кирка, поэтому не стану приписывать различные функции конкретным людям — всё равно где-нибудь ошибусь. ''' @@ -69,7 +79,7 @@ toc::[] FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. Исходный файл с двоичной программой переносится на самый нижний уровень объектов VM. Уровень страниц, копируемых при записи, находится выше него, и хранит те страницы, которые были скопированы из исходного файла. Если программа модифицирует страницы данных, относящиеся к исходному файлу, то система VM обнаруживает это и переносит копию этой страницы на более высокий уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. Это можно показать на простом примере. Функция `fork()` является общей операцией для всех систем *BSD, так что в этом примере будет рассматриваться программа, которая запускается, а затем разветвляется. Когда процесс запускается, VM-система создает некоторый уровень объектов, обозначим его A: -image::fig1.png[Рисунок] +image::fig1.png["Рисунок"] A соответствует файлу-по необходимости страницы памяти могут высвобождаться и подгружаться с носителя файла. Подгрузка с диска может потребоваться программе, однако на самом деле мы не хотим, чтобы она записывалась обратно в файл. Поэтому VM-система создает второй уровень, B, который физически поддерживается дисковым пространством подкачки: @@ -140,20 +150,13 @@ FreeBSD использует несколько очередей страниц Большой процент ошибок доступа к страницам, относится к ошибкам при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `vmstat -s`. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При возникновении ошибки VM-система должна не только выделить новую страницу, но и заполнить ее нулями. Для оптимизации операции по заполнению нулями в системе VM имеется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении ошибок заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. -[[pre-table-optimizations]] +[[page-table-optimizations]] == Оптимизация таблицы страниц Оптимизация таблицы страниц составляет самую содержательную часть архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при значительном использовании `mmap()`. Я думаю, что это на самом деле особенность работы большинства BSD-систем, хотя я не уверен, когда это проявилось впервые. Есть два основных подхода к оптимизации. Первый заключается в том, что аппаратные таблицы страниц не содержат постоянного состояния, а вместо этого могут быть сброшены в любой момент с малыми накладными расходами. Второй подход состоит в том, что каждая активная таблица страниц в системе имеет управляющую структуру `pv_entry`, которая связана в структуру `vm_page`. FreeBSD может просто просматривать эти отображения, которые существуют, когда как в Linux должны проверяться все таблицы страниц, которые _могут_ содержать нужное отображение, что в некоторых ситуация дает увеличение сложности O(n^2). Из-за того, что FreeBSD стремится выбрать наиболее подходящую к повторному использованию или сбросу в область подкачки страницу, когда ощущается нехватка памяти, система дает лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая настройка ядра для соответствия ситуациям с большим совместно используемым адресным пространством, которые могут случиться в системе, обслуживающей сервер телеконференций, потому что структуры `pv_entry` могут оказаться исчерпанными. И в Linux, и во FreeBSD требуются доработки в этой области. FreeBSD пытается максимизировать преимущества от потенциально редко применяемой модели активного отображения (к примеру, не всем процессам нужно отображать все страницы динамической библиотеки), когда как Linux пытается упростить свои алгоритмы. FreeBSD имеет здесь общее преимущество в производительности за счет использования дополнительной памяти, но FreeBSD выглядит хуже в случае, когда большой файл совместно используется сотнями процессов. Linux, с другой стороны, выглядит хуже в случае, когда много процессов частично используют одну и ту же динамическую библиотеку, а также работает неоптимально при попытке определить, может ли страница повторно использоваться, или нет. -[[page-coloring-optimizations]] -== Подгонка страниц - -Мы закончим рассмотрением метода оптимизации подгонкой страниц. Подгонка является методом оптимизации, разработанным для того, чтобы доступ в последовательные страницы виртуальной памяти максимально использовал кэш процессора. В далеком прошлом (то есть больше 10 лет назад) процессорные кэши предпочитали отображать виртуальную память, а не физическую. Это приводило к огромному количеству проблем, включая необходимость очистки кэша в некоторых случаях при каждом переключении контекста и проблемы с замещением данных в кэше. В современных процессорах кэши отображают физическую память именно для решения этих проблем. Это означает, что две соседние страницы в адресном пространстве процессов могут не соответствовать двух соседним страницам в кэше. Фактически, если вы об этом не позаботились, то соседние страницы в виртуальной памяти могут использовать ту же самую страницу в кэше процессора-это приводит к сбросу кэшируемых данных и снижению производительности CPU. Это так даже с множественными ассоциативными кэшами (хотя здесь эффект несколько сглажен). - -Код выделения памяти во FreeBSD выполняет оптимизацию с применением подгонки страниц, означающую то, что код выделения памяти будет пытаться найти свободные страницы, которые являются последовательными с точки зрения кэша. Например, если страница 16 физической памяти назначается странице 0 виртуальной памяти процесса, а в кэш помещается 4 страницы, то код подгонки страниц не будет назначать страницу 20 физической памяти странице 1 виртуальной памяти процесса. Вместо этого будет назначена страница 21 физической памяти. Код подгонки страниц попытается избежать назначение страницы 20, потому что такое отображение перекрывается в той же самой памяти кэша как страница 16, и приведет к неоптимальному кэшированию. Как вы можете предположить, такой код значительно добавляет сложности в подсистему выделения памяти VM, но результат стоит того. Подгонка страниц делает память VM предсказуемой, как и обычная физическая память, относительно производительности кэша. - [[conclusion]] == Заключение @@ -201,23 +204,3 @@ FreeBSD 3.X использует "последовательный список Но во FreeBSD имеется проблема масштабирования, которой нет в Linux, потому что имеется ограниченное число структур `pv_entry`, и это приводит к возникновению проблем при большом объеме совместно используемых данных. В этом случае у вас может возникнуть нехватка структур `pv_entry`, даже если свободной памяти хватает. Это может быть достаточно легко исправлено увеличением количества структур `pv_entry` при настройке, но на самом деле нам нужно найти лучший способ делать это. Что касается использования памяти под таблицу страниц против схемы с `pv_entry`: Linux использует "постоянные" таблицы страниц, которые не сбрасываются, но ему не нужны `pv_entry` для каждого потенциально отображаемого pte. FreeBSD использует "сбрасываемые" таблицы страниц, но для каждого реально отображаемого pte добавляется структура `pv_entry`. Я думаю, что использование памяти будет примерно одинакова, тем более что у FreeBSD есть алгоритмическое преимущество, заключающееся в способности сбрасывать таблицы страниц с очень малыми накладными расходами. - -=== Наконец, в разделе о подгонке страниц хорошо бы было иметь краткое описание того, что это значит. Я не совсем это понял. - -Знаете ли вы, как работает аппаратный кэш памяти L1? Объясняю: Представьте машину с 16МБ основной памяти и только со 128К памяти кэша L1. В общем, этот кэш работает так, что каждый блок по 128К основной памяти использует _те же самые_ 128К кэша. Если вы обращаетесь к основной памяти по смещению 0, а затем к основной памяти по смещению 128К, вы перезаписываете данные кэша, прочтенные по смещению 0! - -Я очень сильно все упрощаю. То, что я только что описал, называется "напрямую отображаемым" аппаратным кэшем памяти. Большинство современных кэшей являются так называемыми 2-сторонними множественными ассоциативными или 4-сторонними множественными ассоциативными кэшами. Множественная ассоциативность позволяет вам обращаться к вплоть до N различным областям памяти, которые используют одну и ту же память кэша без уничтожения ранее помещенных в кэш данных. Но только N. - -Так что если у меня имеется 4-сторонний ассоциативный кэш, я могу обратиться к памяти по смещению 0, смещению 128К, 256К и смещению 384K, затем снова обратиться к памяти по смещению 0 и получу ее из кэша L1. Однако, если после этого я обращусь к памяти по смещению 512К, один из ранее помещенных в кэш объектов данных будет из кэша удален. - -Это чрезвычайно важно... для большинства обращений к памяти процессора _чрезвычайно_ важно, чтобы данные находились в кэше L1, так как кэш L1 работает на тактовой частоте работы процессора. В случае, если данных в кэше L1 не обнаруживается, и они ищутся в кэше L2 или в основной памяти, процессор будет простаивать, или, скорее, сидеть, сложив ручки, в ожидании окончания чтения из основной памяти, хотя за это время можно было выполнить _сотни_ операций. Основная память (динамическое ОЗУ, которое установлено в компьютере) работает по сравнению со скоростью работы ядра современных процессоров __медленно__. - -Хорошо, а теперь рассмотрим подгонку страниц: Все современные кэши памяти являются так называемыми _физическими_ кэшами. Они кэшируют адреса физической памяти, а не виртуальной. Это позволяет кэшу не принимать во внимание переключение контекстов процессов, что очень важно. - -Но в мире UNIX(R) вы работаете с виртуальными адресными пространствами, а не с физическими. Любая программа, вами написанная, имеет дело с виртуальным адресным пространством, ей предоставленным. Реальные _физические_ страницы, соответствующие виртуальному адресному пространству, не обязательно расположены физически последовательно! На самом деле у вас могут оказаться две страницы, которые в адресном пространстве процессов являются граничащими, но располагающимися по смещению 0 и по смещению 128К в _физической_ памяти. - -Обычно программа полагает, что две граничащие страницы будут кэшироваться оптимально. То есть вы можете обращаться к объектам данных в обеих страницах без замещений в кэше данных друг друга. Но это имеет место, если только физические страницы, соответствующие виртуальному адресному пространству, располагаются рядом (в такой мере, что попадают в кэш). - -Это именно то, что выполняет подгонка. Вместо того, чтобы назначать _случайные_ физические страницы виртуальным адресам, что может привести к неоптимальной работе кэша, при подгонке страниц виртуальным адресам назначаются _примерно подходящие по порядку_ физические страницы. Таким образом, программы могут писаться в предположении, что характеристики низлежащего аппаратного кэша для виртуального адресного пространства будут такими же, как если бы программа работала непосредственно в физическом адресном пространстве. - -Заметьте, что я сказал "примерно" подходящие, а не просто "последовательные". С точки зрения напрямую отображаемого кэша в 128К, физический адрес 0 одинаков с физическим адресом 128К. Так что две граничащие страницы в вашем виртуальном адресном пространстве могут располагаться по смещению 128К и 132К физической памяти, но могут легко находиться по смещению 128К и по смещению 4К физической памяти, и иметь те же самые характеристики работы кэша. Так что при подгонке _не нужно_ назначать в действительности последовательные страницы физической памяти последовательным страницам виртуальной памяти, достаточно просто добиться расположения страниц по соседству друг с другом с точки зрения работы кэша. diff --git a/documentation/content/ru/articles/vm-design/_index.po b/documentation/content/ru/articles/vm-design/_index.po new file mode 100644 index 0000000000..8dda5aa52d --- /dev/null +++ b/documentation/content/ru/articles/vm-design/_index.po @@ -0,0 +1,1356 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2025-10-12 22:25+0300\n" +"PO-Revision-Date: 2025-07-05 04:45+0000\n" +"Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" +"Language-Team: Russian <https://translate-dev.freebsd.org/projects/" +"documentation/articlesvm-design_index/ru/>\n" +"Language: ru\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " +"n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" +"X-Generator: Weblate 4.17\n" + +#. type: Yaml Front Matter Hash Value: description +#: documentation/content/en/articles/vm-design/_index.adoc:1 +#, no-wrap +msgid "An easy to follow description of the design of the FreeBSD virtual memory system" +msgstr "Простое и понятное описание архитектуры системы виртуальной памяти FreeBSD" + +#. type: Title = +#: documentation/content/en/articles/vm-design/_index.adoc:1 +#: documentation/content/en/articles/vm-design/_index.adoc:11 +#, no-wrap +msgid "Design elements of the FreeBSD VM system" +msgstr "Элементы архитектуры системы виртуальной памяти во FreeBSD" + +#. type: delimited block = 4 +#: documentation/content/en/articles/vm-design/_index.adoc:46 +msgid "" +"This document is outdated and some sections do not accurately describe the " +"current state of the VM system. It is retained for historical purposes and " +"may be updated over time." +msgstr "" +"Этот документ устарел, и некоторые разделы больше не соответствуют текущему " +"состоянию системы виртуальной памяти. Он сохранён в исторических целях и " +"может быть обновлён в будущем." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:50 +msgid "Abstract" +msgstr "Аннотация" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:52 +msgid "Matthew Dillon <dillon@apollo.backplane.com>" +msgstr "Matthew Dillon <dillon@apollo.backplane.com>" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:59 +msgid "" +"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 subsystems being the most " +"interesting and NFS being \"a necessary chore\". I rewrote only small " +"portions of the code. In the VM arena the only major rewrite I have done is " +"to the swap subsystem. Most of my work was cleanup and maintenance, with " +"only moderate code rewriting and no major algorithmic adjustments within the " +"VM subsystem. The bulk of the VM subsystem's theoretical base remains " +"unchanged and a lot of the credit for the modernization effort in the last " +"few years belongs to John Dyson and David Greenman. Not being a historian " +"like Kirk I will not attempt to tag all the various features with peoples " +"names, since I will invariably get it wrong." +msgstr "" +"Это название — просто замысловатый способ сказать, что я попытаюсь описать " +"всю систему виртуальной памяти (VM) целиком, по возможности так, чтобы это " +"было понятно каждому.В течение последнего года я сосредоточился на " +"нескольких основных подсистемах ядра FreeBSD. Наиболее интересными из них " +"стали подсистемы VM и подкачки (Swap), тогда как работа с NFS оказалась, " +"скорее, «необходимой рутиной». Я переписал лишь небольшие части кода. В " +"области VM моей единственной крупной переработкой стала подсистема подкачки. " +"В основном моя работа заключалась в очистке и поддержке кода, с умеренными " +"правками и без серьёзных изменений алгоритмов в подсистеме VM. Теоретическая " +"основа VM-подсистемы осталась неизменной, и львиная доля заслуг в её " +"модернизации за последние годы принадлежит Джону Дайсону и Дэвиду Гринману. " +"Я не историк, в отличие от Кирка, поэтому не стану приписывать различные " +"функции конкретным людям — всё равно где-нибудь ошибусь." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:61 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:65 +#, no-wrap +msgid "Introduction" +msgstr "Введение" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:81 +msgid "" +"Before moving along to the actual design let's spend a little time on the " +"necessity of maintaining and modernizing any long-living codebase. In the " +"programming world, algorithms tend to be more important than code and it is " +"precisely due to BSD's academic roots that a great deal of attention was " +"paid to algorithm design from the beginning. More attention paid to the " +"design generally leads to a clean and flexible codebase that can be fairly " +"easily modified, extended, or replaced over time. While BSD is considered " +"an \"old\" operating system by some people, those of us who work on it tend " +"to view it more as a \"mature\" 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 " +"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 many other modern " +"operating systems have made. Windows NT(R) is the best example of this, and " +"the consequences have been dire. Linux also makes this mistake to some " +"degree-enough that we BSD folk can make small jokes about it every once in a " +"while, anyway. Linux's problem is simply one of a lack of experience and " +"history to compare ideas against, a problem that is easily and rapidly being " +"addressed by the Linux community in the same way it has been addressed in " +"the BSD community-by continuous code development. The Windows NT(R) folk, " +"on the other hand, repeatedly make the same mistakes solved by UNIX(R) " +"decades ago and then spend years fixing them. Over and over again. They " +"have a severe case of \"not designed here\" and \"we are always right " +"because our marketing department says so\". I have little tolerance for " +"anyone who cannot learn from history." +msgstr "" +"Перед тем, как перейти непосредственно к существующей архитектуре, потратим " +"немного времени на рассмотрение вопроса о необходимости поддержки и " +"модернизации любого длительно живущего кода. В мире программирования " +"алгоритмы становятся более важными, чем код, и именно из-за академических " +"корней BSD изначально большое внимание уделялось проработке алгоритмов. " +"Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости " +"кода, который может быть достаточно легко изменен, расширен или с течением " +"времени заменен. Хотя некоторые считают BSD \"старой\" операционной " +"системой, те их нас, кто работает над ней, видят ее скорее системой со " +"\"зрелым\" кодом с различными компонентами, которые были заменены, расширены " +"или изменены современным кодом. Он развивается, и FreeBSD остается передовой " +"системой, вне зависимости от того, насколько старой может быть часть кода. " +"Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой " +"ошибкой, которую может допустить программист, является игнорирование " +"истории, и это именно та ошибка, которую сделали многие другие современные " +"операционные системы. Самым ярки примером здесь является Windows NT(R), и " +"последствия ужасны. Linux также в некоторой степени совершил эту ошибку-" +"достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому " +"поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории " +"для сравнения идей, проблема, которая легко и быстро решается сообществом " +"Linux точно так же, как она решается в сообществе BSD-постоянной работой над " +"кодом. Разработчики Windows NT(R), с другой стороны, постоянно совершают те " +"же самые ошибки, что были решены в UNIX(R) десятки лет назад, а затем тратят " +"годы на их устранение. Снова и снова. Есть несколько случаев \"проработка " +"архитектуры отсутствует\" и \"мы всегда правы, потому что так говорит наш " +"отдел продаж\". Я плохо переношу тех, кого не учит история." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:86 +msgid "" +"Much of the apparent complexity of the FreeBSD 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:" +msgstr "" +"Большинство очевидной сложности архитектуры FreeBSD, особенно в подсистеме " +"VM/Swap, является прямым следствием того, что она решает серьезные проблемы " +"с производительностью, которые проявляются при различных условиях. Эти " +"проблемы вызваны не плохой проработкой алгоритмов, а возникают из окружающих " +"факторов. В любом прямом сравнении между платформами эти проблемы " +"проявляются, когда системные ресурсы начинают истощаться. Так как я описываю " +"подсистему VM/Swap во FreeBSD, то читатель должен всегда иметь в виду два " +"обстоятельства:" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:88 +msgid "" +"The most important aspect of performance design is what is known as " +"\"Optimizing the Critical Path\". It is often the case that performance " +"optimizations add a little bloat to the code to make the critical path " +"perform better." +msgstr "" +"Самым важным аспектом при проектировании производительности является то, что " +"называется \"оптимизацией критического маршрута\". Часто случается, что " +"оптимизация производительности дает прирост объема кода ради того, чтобы " +"критический маршрут работал быстрее." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:89 +msgid "" +"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." +msgstr "" +"Четкость общей архитектуры оказывается лучше сильно оптимизированной " +"архитектуры с течением времени. Когда как обобщенная архитектура может быть " +"медленнее, чем оптимизированная архитектура, при первой реализации, при " +"обобщенной архитектуре легче подстраиваться под изменяющиеся условия и " +"чрезмерно оптимизированная архитектура оказывается непригодной." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:93 +msgid "" +"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." +msgstr "" +"Любой код, который должен выжить и поддаваться поддержке годы, должен " +"поэтому быть тщательно продуман с самого начала, даже если это стоит потери " +"производительности. Двадцать лет назад были те, кто отстаивал преимущество " +"программирования на языке ассемблера перед программированием на языке " +"высокого уровня, потому что первый генерировал в десять раз более быстрый " +"код. В наши дни ошибочность этого аргумента очевидна - можно провести " +"параллели с построением алгоритмов и обобщением кода." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:95 +#, no-wrap +msgid "VM Objects" +msgstr "Объекты VM" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:105 +msgid "" +"The best way to begin describing the FreeBSD 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 code and " +"program data are effectively a single memory-mapped file (the binary file " +"being run), but program code is read-only while program data is copy-on-" +"write. Program BSS is just memory allocated and filled with zeros on " +"demand, called demand zero page fill. Arbitrary files can be memory-mapped " +"into the address space as well, which is how the shared library mechanism " +"works. Such mappings can require modifications to remain private to the " +"process making them. The fork system call adds an entirely new dimension to " +"the VM management problem on top of the complexity already given." +msgstr "" +"Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на нее с " +"точки зрения пользовательского процесса. Каждый пользовательский процесс " +"имеет единое, принадлежащее только ему и неразрывное адресное пространство " +"VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные " +"характеристики. Код программы и ее данные являются единым файлом, " +"отображаемым в память (это выполняющийся двоичный файл), однако код " +"программы доступен только для чтения, когда как данные программы размещаются " +"в режиме копирования-при-записи. BSS программы представляет собой всего лишь " +"выделенную область памяти, заполненную, если это требовалось, нулями, что " +"называется обнулением страниц памяти по требованию. Отдельные файлы могут " +"также отображаться в адресное пространство, именно так работают динамические " +"библиотеки. Такие отображения требуют изменений, чтобы оставаться " +"принадлежащими процессу, который их выполнил. Системный вызов fork добавляет " +"переводит проблему управления VM полностью в новую плоскость, вдобавок к уже " +"имеющимся сложностям." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:111 +msgid "" +"A program binary data page (which is a basic copy-on-write page) illustrates " +"the complexity. A program binary contains a preinitialized data section " +"which is initially mapped directly from the program file. When a program is " +"loaded into a process's VM space, this area is initially memory-mapped and " +"backed by the program binary itself, allowing the VM system to free/reuse " +"the page and later load it back in from the binary. The moment a process " +"modifies this data, however, the VM system must make a private copy of the " +"page for that process. Since the private copy has been modified, the VM " +"system may no longer free it, because there is no longer any way to restore " +"it later on." +msgstr "" +"Иллюстрирует сложность страница данных двоичной программы (которая является " +"страницей копируемой-при-записи). Двоичная программа содержит секцию " +"предварительно инициализированных данных, которая первоначально отображается " +"непосредственно из файла программы. Когда программа загружается в Vm-" +"пространство процесса, эта область сначала отображается в память и " +"поддерживается бинарным файлом программы, позволяя VM-системе освобождать/" +"повторно использовать страницу, а потом загружать ее снова из бинарного " +"файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна " +"сделать копию страницы, принадлежащую только этому процессу. Так как эта " +"копия была изменена, то VM-система не может больше освобождать эту страницу, " +"так как впоследствии ее невозможно будет восстановить." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:118 +msgid "" +"You will notice immediately that what was originally a simple file mapping " +"has become much more complex. Data may be modified on a page-by-page basis " +"whereas the file mapping encompasses many pages at once. The complexity " +"further increases when a process forks. When a process forks, the result is " +"two processes-each with their own private address spaces, including any " +"modifications made by the original process prior to the call to `fork()`. " +"It would be silly for the VM system to make a complete copy of the data at " +"the time of the `fork()` because it is quite possible that at least one of " +"the two processes will only need to read from that page from then on, " +"allowing the original page to continue to be used. What was a private page " +"is made copy-on-write again, since each process (parent and child) expects " +"their own personal post-fork modifications to remain private to themselves " +"and not affect the other." +msgstr "" +"Вы тут же заметите, что то, что сначала было простым отображением файла в " +"память, становится гораздо более сложным предметом. Данные могут " +"модифицироваться постранично, когда как отображение файла выполняется для " +"многих страниц за раз. Сложность еще более увеличивается, когда процесс " +"выполняет вызов fork. При этом порождаются два процесса-каждый со с " +"собственным адресным пространством, включающим все изменения, выполненные " +"исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы " +"делать полную копию данных во время вызова `fork()`, так как весьма " +"вероятно, что один из двух процессов будет нужен только для чтения из той " +"страницы, что позволяет использование исходной страницы. То, что было " +"страницей, принадлежащей только процессу, сделается снова страницей, " +"копируемой при записи, так как каждый из процессов (и родитель, и потомок) " +"полагают, что их собственные изменения после разветвления будут принадлежать " +"только им, и не затронут родственный процесс." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:127 +msgid "" +"FreeBSD 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 page " +"belonging to the original file the VM system takes a fault and makes a copy " +"of the page in the higher layer. When a process forks, additional VM Object " +"layers are pushed on. This might make a little more sense with a fairly " +"basic example. A `fork()` is a common operation for any *BSD system, so " +"this example will consider a program that starts up, and forks. When the " +"process starts, the VM system creates an object layer, let's call this A:" +msgstr "" +"FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. " +"Исходный файл с двоичной программой переносится на самый нижний уровень " +"объектов VM. Уровень страниц, копируемых при записи, находится выше него, и " +"хранит те страницы, которые были скопированы из исходного файла. Если " +"программа модифицирует страницы данных, относящиеся к исходному файлу, то " +"система VM обнаруживает это и переносит копию этой страницы на более высокий " +"уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. " +"Это можно показать на простом примере. Функция `fork()` является общей " +"операцией для всех систем *BSD, так что в этом примере будет рассматриваться " +"программа, которая запускается, а затем разветвляется. Когда процесс " +"запускается, VM-система создает некоторый уровень объектов, обозначим его A:" + +#. type: Positional ($1) AttributeList argument for macro 'image' +#: documentation/content/en/articles/vm-design/_index.adoc:128 +#, no-wrap +msgid "A picture" +msgstr "Рисунок" + +#. type: Target for macro image +#: documentation/content/en/articles/vm-design/_index.adoc:128 +#, no-wrap +msgid "fig1.png" +msgstr "fig1.png" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:133 +msgid "" +"A represents the file-pages may be paged in and out of the file's physical " +"media as necessary. Paging in from the disk is reasonable for a program, " +"but we really do not want to page back out and overwrite the executable. " +"The VM system therefore creates a second layer, B, that will be physically " +"backed by swap space:" +msgstr "" +"A соответствует файлу-по необходимости страницы памяти могут высвобождаться " +"и подгружаться с носителя файла. Подгрузка с диска может потребоваться " +"программе, однако на самом деле мы не хотим, чтобы она записывалась обратно " +"в файл. Поэтому VM-система создает второй уровень, B, который физически " +"поддерживается дисковым пространством подкачки:" + +#. type: Target for macro image +#: documentation/content/en/articles/vm-design/_index.adoc:134 +#, no-wrap +msgid "fig2.png" +msgstr "fig2.png" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:139 +msgid "" +"On the first write to a page after this, a new page is created in B, and its " +"contents are initialized from A. All pages in B can be paged in or out to a " +"swap device. When the program forks, the VM system creates two new object " +"layers-C1 for the parent, and C2 for the child-that rest on top of B:" +msgstr "" +"При первой записи в страницу после выполнения этой операции, в B создается " +"новая страница, содержимое которой берется из A. Все страницы в B могут " +"сбрасываться и считываться из устройства подкачки. Когда программа ветвится, " +"VM-система создает два новых уровня объектов-C1 для порождающего процесса и " +"C2 для порожденного-они располагаются поверх B:" + +#. type: Target for macro image +#: documentation/content/en/articles/vm-design/_index.adoc:140 +#, no-wrap +msgid "fig3.png" +msgstr "fig3.png" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:151 +msgid "" +"In this case, let's say a page in B is modified by the original parent " +"process. The process will take a copy-on-write fault and duplicate the page " +"in C1, leaving the original page in B untouched. Now, let's say the same " +"page in B is modified by the child process. The process will take a copy-on-" +"write fault and duplicate the page in C2. 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 \"real\" file; however, this sort of " +"optimization is not trivial to make because it is so fine-grained. FreeBSD " +"does not make this optimization. Now, suppose (as is often the case) that " +"the child process does an `exec()`. Its current address space is usually " +"replaced by a new address space representing a new file. In this case, the " +"C2 layer is destroyed:" +msgstr "" +"В этом случае, допустим, что страница в B была изменена начальным " +"родительским процессом. В процессе возникнет ситуация копирования при записи " +"и страница скопируется в C1, при этом исходная страница останется в B " +"нетронутой. Теперь допустим, что та же самая страница в B изменяется " +"порожденным процессом. В процессе возникнет ситуация копирования при записи " +"и страница скопируется в C2. Исходная страница в B теперь полностью скрыта, " +"так как и C1, и C2 имеют копии, а B теоретически может быть уничтожена, если " +"она не представляет собой \"реального\" файла). Однако такую оптимизацию не " +"так уж просто осуществить, потому что она делается на уровне мелких единиц. " +"Во FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто " +"случается), что порожденный процесс выполняет вызов `exec()`. Его текущее " +"адресное пространство обычно заменяется новым адресным пространством, " +"представляющим новый файл. В этом случае уровень C2 уничтожается:" + +#. type: Target for macro image +#: documentation/content/en/articles/vm-design/_index.adoc:152 +#, no-wrap +msgid "fig4.png" +msgstr "fig4.png" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:158 +msgid "" +"In this case, the number of children of B drops to one, and all accesses to " +"B now go through C1. This means that B and C1 can be collapsed together. " +"Any pages in B that also exist in C1 are deleted from B during the " +"collapse. Thus, even though the optimization in the previous step could not " +"be made, we can recover the dead pages when either of the processes exit or " +"`exec()`." +msgstr "" +"В этом случае количество потомков B становится равным одному и все обращения " +"к B теперь выполняются через C1. Это означает, что B и C1 могут быть " +"объединены. Все страницы в B, которые также существуют и в C1, во время " +"объединения из B удаляются. Таким образом, хотя оптимизация на предыдущем " +"шаге может не делаться, мы можем восстановить мертвые страницы при окончании " +"работы процессов или при вызове `exec()`." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:165 +msgid "" +"This model creates a number of potential problems. The first is that you " +"can wind up with a relatively deep stack of layered VM Objects which can " +"cost scanning time and memory when you take a fault. Deep layering can " +"occur when processes fork and then fork again (either parent or child). The " +"second problem is that you can wind up with dead, inaccessible pages deep in " +"the stack of VM Objects. In our last example if both the parent and child " +"processes modify the same page, they both 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." +msgstr "" +"Такая модель создает некоторое количество потенциальных проблем. Первая, с " +"которой вы можете столкнуться, заключается в сравнительно большой " +"последовательности уровней объектов VM, на сканирование которых тратится " +"время и память. Большое количество уровней может возникнуть, когда процессы " +"разветвляются, а затем разветвляются еще раз (как порожденные, так и " +"порождающие). Вторая проблема заключается в том, что вы можете столкнуться с " +"мертвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем " +"последнем примере если как родитель, так и потомок изменяют одну и ту же " +"страницу, они оба получают собственные копии страницы, а исходная страница в " +"B становится никому не доступной. такая страница в B может быть высвобождена." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:176 +msgid "" +"FreeBSD solves the deep layering problem with a special optimization called " +"the \"All Shadowed Case\". 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 then have C1->B->A " +"and C2->B->A we now have C1->A and C2->B->A. But look what also happened-" +"now B has only one reference (C2), so we can collapse B and C2 together. " +"The end result is that B is deleted entirely and we have C1->A and C2->A. " +"It is often the case that B will contain a large number of pages and neither " +"C1 nor C2 will be able to completely overshadow it. If we fork again and " +"create a set of D layers, however, it is much more likely that one of the D " +"layers will eventually be able to completely overshadow the much smaller " +"dataset represented by C1 or C2. The same optimization will work at any " +"point in the graph and the grand result of this is that even on a heavily " +"forked machine VM Object stacks tend to not get much deeper then 4. This is " +"true of both the parent and the children and true whether the parent is " +"doing the forking or whether the children cascade forks." +msgstr "" +"FreeBSD решает проблему с глубиной вложенности с помощью приема оптимизации, " +"который называется \"All Shadowed Case\". Этот случай возникает, если в C1 " +"либо C2 возникает столько случаев копирования страниц при записи, что они " +"полностью закрывают все страницы в B. Допустим, что такое произошло в C1. C1 " +"может теперь полностью заменить B, так что вместо цепочек C1->B->A и C2->B-" +">A мы теперь имеем цепочки C1->A и C2->B->A. Но посмотрите, что получается-" +"теперь B имеет только одну ссылку (C2), так что мы можем объединить B и C2. " +"В конечном итоге B будет полностью удален и мы имеем цепочки C1->A и C2->A. " +"Часто B будет содержать большое количество страниц, и ни C1, ни C2 не смогут " +"полностью их заменить. Если мы снова породим процесс и создадим набор " +"уровней D, при этом, однако, более вероятно, что один из уровней D " +"постепенно сможет полностью заместить гораздо меньший набор данных, " +"представленный C1 и C2. Та же самая оптимизация будет работать в любой точке " +"графа и главным результатом этого является то, что даже на сильно " +"загруженной машине с множеством порождаемых процессов стеки объектов VM не " +"часто бывают глубже четырех уровней. Это так как для порождающего, так и для " +"порожденного процессов, и остается в силе как в случае, когда ветвление " +"делает родитель, так и в случае, когда ветвление выполняет потомок." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:180 +msgid "" +"The dead page problem still exists in the case where C1 or C2 do not " +"completely overshadow B. Due to our other optimizations this case does not " +"represent much of a problem and we simply allow the pages to be dead. If " +"the system runs low on memory it will swap them out, eating a little swap, " +"but that is it." +msgstr "" +"Проблема с мертвой страницей все еще имеет место, когда C1 или C2 не " +"полностью перекрывают B. Из-за других применяемых нами методов оптимизации " +"этот случай не представляет большой проблемы и мы просто позволяем таким " +"страницам существовать. Если система испытывает нехватку оперативной памяти, " +"она выполняет их выгрузку в область подкачки, что занимает некоторое " +"пространство в области подкачки, но это все." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:184 +msgid "" +"The advantage to the VM Object model is that `fork()` is extremely fast, " +"since no real data 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 that they can be ignored, leaving no real disadvantage." +msgstr "" +"Преимущество модели VM-объектов заключается в очень быстром выполнении " +"функции `fork()`, так как при этом не выполняется реального копирования " +"данных. Минусом этого подхода является то, что вы можете построить " +"сравнительно сложную иерархию объектов VM, которая несколько замедляет " +"обработку ситуаций отсутствия страниц памяти, и к тому же тратится память на " +"управление структурами объектов VM. Приемы оптимизации, применяемые во " +"FreeBSD, позволяют снизить значимость этих проблем до степени, когда их " +"можно без особых потерь игнорировать." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:186 +#, no-wrap +msgid "SWAP Layers" +msgstr "Уровни области подкачки" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:194 +msgid "" +"Private data pages are initially either copy-on-write or zero-fill pages. " +"When a change, and therefore a copy, is made, the original 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 management structure for a VM " +"Object only when it is actually needed. However, the swap management " +"structure has had problems historically:" +msgstr "" +"Страницы с собственными данными первоначально являются страницами, " +"копируемыми при записи или заполняемыми нулями. Когда выполняется изменение, " +"и, соответственно, копирование, начальное хранилище объекта (обычно файл) не " +"может больше использоваться для хранения копии страницы, когда VM-системе " +"нужно использовать ее повторно для других целей. В этот момент на помощь " +"приходит область подкачки. Область подкачки выделяется для организации " +"хранилища памяти, которая иначе не может быть доступна. FreeBSD создает " +"структуру управления подкачкой для объекта VM, только когда это " +"действительно нужно. Однако структура управления подкачкой исторически имела " +"некоторые проблемы:" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:196 +msgid "" +"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." +msgstr "" +"Во FreeBSD 3.X в структуре управления областью подкачки предварительно " +"выделяется массив, который представляет целый объект, требующий хранения в " +"области подкачки-даже если только несколько страниц этого объекта хранятся в " +"области подкачки. Это создает проблему фрагментации памяти ядра в случае, " +"когда в память отображаются большие объекты или когда ветвятся процессы, " +"занимающие большой объем памяти при работе (RSS)." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:197 +msgid "" +"Also, to keep track of swap space, a \"list of holes\" is kept in kernel " +"memory, and this tends to get severely fragmented as well. Since the \"list " +"of holes\" is a linear list, the swap allocation and freeing performance is " +"a non-optimal O(n)-per-page." +msgstr "" +"Также для отслеживания памяти подкачки в памяти ядра поддерживается \"список " +"дыр\", и он также несколько фрагментирован. Так как \"список дыр\" является " +"последовательным списком, то производительность при распределении и " +"высвобождении памяти в области подкачки неоптимально и ее сложность зависит " +"от количества страниц как O(n)." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:198 +msgid "" +"It requires kernel memory allocations to take place during the swap freeing " +"process, and that creates low memory deadlock problems." +msgstr "" +"Также в процессе высвобождения памяти в области подкачки требуется выделение " +"памяти в ядре, и это приводит к проблемам блокировки при недостатке памяти." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:199 +msgid "" +"The problem is further exacerbated by holes created due to the interleaving " +"algorithm." +msgstr "" +"Проблема еще более обостряется из-за дыр, создаваемых по чередующемуся " +"алгоритму." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:200 +msgid "" +"Also, the swap block map can become fragmented fairly easily resulting in " +"non-contiguous allocations." +msgstr "" +"Кроме того, список распределения блоков в области подкачки легко оказывается " +"фрагментированным, что приводит к распределению непоследовательных областей." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:201 +msgid "" +"Kernel memory must also be allocated on the fly for additional swap " +"management structures when a swapout occurs." +msgstr "" +"Память ядра также должна распределяться по ходу работы для дополнительных " +"структур по управлению областью подкачки при выгрузке страниц памяти в эту " +"область." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:204 +msgid "" +"It is evident from that list that there was plenty of room for improvement. " +"For FreeBSD 4.X, I completely rewrote the swap subsystem:" +msgstr "" +"Очевидно, что мест для усовершенствований предостаточно. Во FreeBSD 4.X " +"подсистема управления областью подкачки была полностью переписана мною:" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:206 +msgid "" +"Swap management structures are allocated through a hash table rather than a " +"linear array giving them a fixed allocation size and much finer granularity." +msgstr "" +"Структуры управления областью подкачки распределяются при помощи хэш-" +"таблицы, а не через линейный массив, что дает им фиксированный размер при " +"распределении и работу с гораздо меньшими структурами." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:207 +msgid "" +"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." +msgstr "" +"Вместо того, чтобы использовать однонаправленный связный список для " +"отслеживания выделения пространства в области подкачки, теперь используется " +"побитовая карта блоков области подкачки, выполненная в основном в виде " +"древовидной структуры с информацией о свободном пространстве, находящейся в " +"узлах структур. Это приводит к тому, что выделение и высвобождение памяти в " +"области подкачки становится операцией сложности O(1)." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:208 +msgid "" +"The entire radix tree bitmap is also preallocated 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 to avoid potential deadlocks." +msgstr "" +"Все дерево также распределяется заранее для того, чтобы избежать " +"распределения памяти ядра во время операций с областью подкачки при " +"критически малом объеме свободной памяти. В конце концов, система обращается " +"к области подкачки при нехватке памяти, так что мы должны избежать " +"распределения памяти ядра в такие моменты для избежания потенциальных " +"блокировок." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:209 +msgid "" +"To reduce fragmentation the radix tree is capable of allocating large " +"contiguous chunks at once, skipping over smaller fragmented chunks." +msgstr "" +"Для уменьшения фрагментации дерево может распределять большой " +"последовательный кусок за раз, пропуская меньшие фрагментированные области." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:211 +msgid "" +"I did not take the final step of having an \"allocating hint pointer\" that " +"would trundle through a portion of swap as allocations were made to further " +"guarantee contiguous allocations or at least locality of reference, but I " +"ensured that such an addition could be made." +msgstr "" +"Я не сделал последний шаг к заведению \"указателя на распределение\", " +"который будет передвигаться по участку области подкачки при выделении памяти " +"для обеспечения в будущем распределения последовательных участков, или по " +"крайней мере местоположения ссылки, но я убежден, что это может быть сделано." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:213 +#, no-wrap +msgid "When to free a page" +msgstr "Когда освобождать страницу" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:218 +msgid "" +"Since the VM system uses all available memory for disk caching, there are " +"usually very few truly-free pages. The VM system depends on being able to " +"properly choose pages which are not in use to reuse for new allocations. " +"Selecting the optimal pages to free is possibly the single-most important " +"function any VM system can perform because if it makes a poor selection, the " +"VM system may be forced to unnecessarily retrieve pages from disk, seriously " +"degrading system performance." +msgstr "" +"Так как система VM использует всю доступную память для кэширования диска, то " +"обычно действительно незанятых страниц очень мало. Система VM зависит от " +"того, как она точно выбирает незанятые страницы для повторного использования " +"для новых распределений. Оптимальный выбор страниц для высвобождения, " +"возможно, является самой важной функцией любой VM-системы, из тех, что она " +"может выполнять, потому что при неправильном выборе система VM вынуждена " +"будет запрашивать страницы с диска, значительно снижая производительность " +"всей системы." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:221 +msgid "" +"How much overhead are we willing to suffer in the critical path to avoid " +"freeing the wrong page? Each wrong choice we make will cost us 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 to be sure that " +"the right page is chosen. This is why FreeBSD tends to outperform other " +"systems when memory resources become stressed." +msgstr "" +"Какую дополнительную нагрузку мы может выделить в критическом пути для " +"избежания высвобождения не той страницы? Каждый неправильный выбор будет " +"стоить нам сотни тысяч тактов работы центрального процессора и заметное " +"замедление работы затронутых процессов, так что мы должны смириться со " +"значительными издержками для того, чтобы была заведомо выбрана правильная " +"страница. Вот почему FreeBSD превосходит другие системы в производительности " +"при нехватке ресурсов памяти." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:224 +msgid "" +"The free page determination algorithm is built upon a history of the use of " +"memory pages. To acquire this history, the system takes advantage of a page-" +"used bit feature that most hardware page tables have." +msgstr "" +"Алгоритм определения свободной страницы написан на основе истории " +"использования страниц памяти. Для получения этой истории система использует " +"возможности бита использования памяти, которые имеются в большинстве " +"аппаратных таблицах страниц памяти." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:230 +msgid "" +"In any case, the page-used bit is cleared and at some later point the VM " +"system comes across the page again and sees that the page-used bit has been " +"set. This indicates that the page is still being actively used. If the bit " +"is still clear it is an indication that the page is not being actively " +"used. By testing this bit periodically, a use history (in the form of a " +"counter) for the physical page is developed. When the VM system later needs " +"to free up some pages, checking this history becomes the cornerstone of " +"determining the best candidate page to reuse." +msgstr "" +"В любом случае, бит использования страницы очищается, и в некоторый более " +"поздний момент VM-система обращается к странице снова и обнаруживает, что " +"этот бит установлен. Это указывает на то, что страница активно используется. " +"Периодически проверяя этот бит, накапливается история использования (в виде " +"счетчика) физической страницы. Когда позже VM-системе требуется высвободить " +"некоторые страницы, проверка истории выступает указателем при определении " +"наиболее вероятной кандидатуры для повторного использования." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:235 +msgid "" +"For those platforms that do not have this feature, the system actually " +"emulates a page-used bit. It unmaps or protects a page, forcing a page " +"fault if the page is accessed again. When the page fault is taken, the " +"system simply marks the page as having been used and unprotects the page so " +"that it may be used. While taking such page faults just to determine if a " +"page is being used appears to be an expensive proposition, it is much less " +"expensive than reusing the page for some other purpose only to find that a " +"process needs it back and then have to go to disk." +msgstr "" +"Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. " +"Она снимает отображение или защищает страницу, что приводит к ошибке доступа " +"к странице, если к странице выполняется повторное обращение. При " +"возникновении этой ошибки система просто помечает страницу как используемую " +"и снимает защиту со страницы, так что она может использоваться. Хотя " +"использование такого приема только для определения использования страницы " +"весьма накладно, это выгоднее, чем повторно использовать страницу для других " +"целей и обнаружить, что она снова нужна процессу и подгружать ее с диска." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:245 +msgid "" +"FreeBSD 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 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 theoretically be freed up at any " +"time, and dirty pages which must first be written to their backing store " +"before being reusable. When a page candidate has been found it is moved to " +"the inactive queue if it is dirty, or the cache queue if it is clean. A " +"separate algorithm based on the dirty-to-clean page ratio determines when " +"dirty pages in the inactive queue must be flushed to disk. Once this is " +"accomplished, the flushed pages are moved from the inactive queue to the " +"cache queue. At this point, pages in the cache queue can still be " +"reactivated by a VM fault at relatively low cost. However, pages in the " +"cache queue are considered to be \"immediately freeable\" and will be reused " +"in an LRU (least-recently used) fashion when the system needs to allocate " +"new memory." +msgstr "" +"FreeBSD использует несколько очередей страниц для обновления выбора страниц " +"для повторного использования, а также для определения того, когда же грязные " +"страницы должны быть сброшены в хранилище. Так как таблицы страниц во " +"FreeBSD являются динамическими объектами, практически ничего не стоит " +"вырезать страницу из адресного пространства любого использующего ее " +"процесса. После того, как подходящая страница, на основе счетчика " +"использования, выбрана, именно это и выполняется. Система должна отличать " +"между чистыми страницами, которые теоретически могут быть высвобождены в " +"любое время, и грязными страницами, которые сначала должны быть переписаны в " +"хранилище перед тем, как их можно будет использовать повторно. После " +"нахождения подходящей страницы она перемещается в неактивную очередь, если " +"она является грязной, или в очередь кэша, если она чистая. Отдельный " +"алгоритм, основывающийся на отношении количества грязных страниц к чистым, " +"определяет, когда грязные страницы в неактивной очереди должны быть сброшены " +"на диск. Когда это выполнится, сброшенные страницы перемещаются из " +"неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша " +"могут быть повторно активизированы VM со сравнительно малыми накладными " +"расходами. Однако страницы в очереди кэша предполагается \"высвобождать " +"немедленно\" и повторно использовать в LRU-порядке (меньше всего " +"используемый), когда системе потребуется выделение дополнительной памяти." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:249 +msgid "" +"It is important to note that the FreeBSD 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 memory subsystem is not being " +"stressed. This is why you will see some systems with very low cache queue " +"counts and high active queue counts when doing a `systat -vm` 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." +msgstr "" +"Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и " +"грязные страницы во избежание срочной необходимости в ненужных сбросах " +"грязных страниц (что отражается на пропускной способности ввода/вывода) и не " +"перемещает беспричинно страницы между разными очередями, когда подсистема " +"управления памятью не испытывает нехватку ресурсов. Вот почему вы можете " +"видеть, что при выполнении команды `systat -vm` в некоторых системах " +"значение счетчика очереди кэша мало, а счетчик активной очереди большой. При " +"повышении нагрузки на VM-систему она прилагает большие усилия на поддержку " +"различных очередей страниц в соотношениях, которые являются наиболее " +"эффективными." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:253 +msgid "" +"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 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." +msgstr "" +"Годами ходили современные легенды, что Linux выполняет работу по " +"предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом " +"деле FreeBSD старается сбросить на диск неиспользуемые страницы для " +"освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые " +"страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я " +"не знаю, остается ли это правдой на сегодняшний день." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:255 +#, no-wrap +msgid "Pre-Faulting and Zeroing Optimizations" +msgstr "Оптимизация ошибок доступа к страницам и их обнуления" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:265 +msgid "" +"Taking a VM fault is not expensive if the underlying page is already in core " +"and can simply be mapped into the process, but it can become expensive if " +"you take a whole lot of them on a regular basis. A good example of this is " +"running a program such as man:ls[1] or man:ps[1] over and over again. If " +"the program binary is mapped into memory but 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 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 example, if you run the man:ls[1] program while " +"running `vmstat 1` you will notice that it always takes a certain number of " +"page faults, even when you run it over and over again. These are zero-fill " +"faults, not program code faults (which were pre-faulted in already). Pre-" +"copying pages on exec or fork is an area that could use more study." +msgstr "" +"Полагая, что ошибка доступа к странице памяти в VM не является операцией с " +"большими накладными расходами, если страница уже находится в основной памяти " +"и может быть просто отображена в адресное пространство процесса, может " +"оказаться, что это станет весьма накладно, если их будет оказываться " +"регулярно много. Хорошим примером этой ситуации является запуск таких " +"программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл " +"программы отображен в память, но не отображен в таблицу страниц, то все " +"страницы, к которым обращалась программа, окажутся недоступными при каждом " +"запуске программы. Это не так уж необходимо, если эти страницы уже " +"присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать " +"таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. " +"Однако во FreeBSD пока не выполняется предварительное копирование при записи " +"определенных страниц при выполнении вызова exec. Например, если вы " +"запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то " +"заметите, что она всегда выдает некоторое количество ошибок доступа к " +"страницам, даже когда вы запускаете ее снова и снова. Это ошибки заполнения " +"нулями, а не ошибки кода программы (которые уже были обработаны). " +"Предварительное копирование страниц при выполнении вызовов exec или fork " +"находятся в области, требующей более тщательного изучения." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:274 +msgid "" +"A large percentage of page faults that occur are zero-fill faults. You can " +"usually see this by observing the `vmstat -s` output. These occur when a " +"process accesses pages in its BSS area. The BSS area is expected to be " +"initially zero but the VM system does not bother to allocate any memory at " +"all until the process actually accesses it. When a fault occurs the VM " +"system must not only allocate a new page, it must zero it as well. To " +"optimize the zeroing operation the VM system has the ability to pre-zero " +"pages and mark them as such, and to request pre-zeroed pages when zero-fill " +"faults occur. The pre-zeroing occurs whenever the CPU is idle but the " +"number of pages the system pre-zeros is limited to avoid blowing away the " +"memory caches. This is an excellent example of adding complexity to the VM " +"system to optimize the critical path." +msgstr "" +"Большой процент ошибок доступа к страницам, относится к ошибкам при " +"заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды " +"`vmstat -s`. Это происходит, когда процесс обращается к страницам в своей " +"области BSS. Область BSS предполагается изначально заполненной нулями, но VM-" +"система не заботится о выделении памяти до тех пор, пока процесс реально к " +"ней не обратится. При возникновении ошибки VM-система должна не только " +"выделить новую страницу, но и заполнить ее нулями. Для оптимизации операции " +"по заполнению нулями в системе VM имеется возможность предварительно " +"обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при " +"возникновении ошибок заполнения нулями. Предварительное заполнение нулями " +"происходит, когда CPU простаивает, однако количество страниц, которые " +"система заранее заполняет нулями, ограничено, для того, чтобы не переполнить " +"кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради " +"оптимизации критического пути." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:276 +#, no-wrap +msgid "Page Table Optimizations" +msgstr "Оптимизация таблицы страниц" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:286 +msgid "" +"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 serious " +"use of `mmap()`. 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 tables do not contain " +"persistent state but instead can be thrown away at 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 `pv_entry` structure which is tied " +"into the `vm_page` structure. FreeBSD can simply iterate through those " +"mappings that are known to exist while Linux must check all page tables that " +"_might_ 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 choices on which pages to reuse or swap when memory is " +"stressed, giving it better performance under load. However, FreeBSD " +"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 " +"`pv_entry` structures." +msgstr "" +"Оптимизация таблицы страниц составляет самую содержательную часть " +"архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при " +"значительном использовании `mmap()`. Я думаю, что это на самом деле " +"особенность работы большинства BSD-систем, хотя я не уверен, когда это " +"проявилось впервые. Есть два основных подхода к оптимизации. Первый " +"заключается в том, что аппаратные таблицы страниц не содержат постоянного " +"состояния, а вместо этого могут быть сброшены в любой момент с малыми " +"накладными расходами. Второй подход состоит в том, что каждая активная " +"таблица страниц в системе имеет управляющую структуру `pv_entry`, которая " +"связана в структуру `vm_page`. FreeBSD может просто просматривать эти " +"отображения, которые существуют, когда как в Linux должны проверяться все " +"таблицы страниц, которые _могут_ содержать нужное отображение, что в " +"некоторых ситуация дает увеличение сложности O(n^2). Из-за того, что FreeBSD " +"стремится выбрать наиболее подходящую к повторному использованию или сбросу " +"в область подкачки страницу, когда ощущается нехватка памяти, система дает " +"лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая " +"настройка ядра для соответствия ситуациям с большим совместно используемым " +"адресным пространством, которые могут случиться в системе, обслуживающей " +"сервер телеконференций, потому что структуры `pv_entry` могут оказаться " +"исчерпанными." + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:291 +msgid "" +"Both Linux and FreeBSD need work in this area. FreeBSD 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 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 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 whether a page can be " +"reused or not." +msgstr "" +"И в Linux, и во FreeBSD требуются доработки в этой области. FreeBSD пытается " +"максимизировать преимущества от потенциально редко применяемой модели " +"активного отображения (к примеру, не всем процессам нужно отображать все " +"страницы динамической библиотеки), когда как Linux пытается упростить свои " +"алгоритмы. FreeBSD имеет здесь общее преимущество в производительности за " +"счет использования дополнительной памяти, но FreeBSD выглядит хуже в случае, " +"когда большой файл совместно используется сотнями процессов. Linux, с другой " +"стороны, выглядит хуже в случае, когда много процессов частично используют " +"одну и ту же динамическую библиотеку, а также работает неоптимально при " +"попытке определить, может ли страница повторно использоваться, или нет." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:293 +#, no-wrap +msgid "Conclusion" +msgstr "Заключение" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:298 +msgid "" +"Virtual memory in modern operating systems must address a number of " +"different issues efficiently and for many different usage patterns. The " +"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 years, and work is " +"ongoing." +msgstr "" +"Виртуальная память в современных операционных системах должна решать " +"несколько различных задач эффективно и при разных условиях. Модульный и " +"алгоритмический подход, которому исторически следует BSD, позволяет нам " +"изучить и понять существующую реализацию, а также сравнительно легко " +"изменить большие блоки кода. За несколько последних лет в VM-системе FreeBSD " +"было сделано некоторое количество усовершенствований, и работа над ними " +"продолжается." + +#. type: Title == +#: documentation/content/en/articles/vm-design/_index.adoc:300 +#, no-wrap +msgid "Bonus QA session by Allen Briggs" +msgstr "Дополнительный сеанс вопросов и ответов от Аллена Бриггса (Allen Briggs)" + +#. type: Title === +#: documentation/content/en/articles/vm-design/_index.adoc:302 +#, no-wrap +msgid "What is the interleaving algorithm that you refer to in your listing of the ills of the FreeBSD 3.X swap arrangements?" +msgstr "Что это за алгоритм чередования, который вы упоминали в списке недостатков подсистемы управления разделом подкачки во FreeBSD 3.X?" + +#. type: .abstract-title +#: documentation/content/en/articles/vm-design/_index.adoc:308 +msgid "" +"FreeBSD uses a fixed swap interleave which defaults to 4. This means that " +"FreeBSD 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 \"four swap areas\" 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 space representation for that swap area will be interleaved in " +"blocks of 16 pages:" +msgstr "" +"FreeBSD использует в области подкачки механизм чередования, с индексом по " +"умолчанию, равным четырем. Это означает, что FreeBSD резервирует " +"пространство для четырех областей подкачки, даже если у вас имеется всего " +"лишь одна, две или три области. Так как в области подкачки имеется " +"чередование, то линейное адресное пространство, представляющее \"четыре " +"области подкачки\", будет фрагментироваться, если у вас нет на самом деле " +"четырех областей подкачки. Например, если у вас две области A и B, то " +"представление адресного пространства для этой области подкачки во FreeBSD " +"будет организовано с чередованием блоков из 16 страниц:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/vm-design/_index.adoc:311 +#, no-wrap +msgid "A B C D A B C D A B C D A B C D\n" +msgstr "A B C D A B C D A B C D A B C D\n" + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:318 +msgid "" +"FreeBSD 3.X uses a \"sequential list of free regions\" approach to " +"accounting for the free swap areas. The idea is that large blocks of free " +"linear space can be represented with a single list node ([.filename]#kern/" +"subr_rlist.c#). But due to the fragmentation the sequential list winds up " +"being insanely fragmented. In the above example, completely unused swap " +"will have A and B shown as \"free\" and C and D shown as \"all allocated\". " +"Each A-B sequence requires a list node to account for because C and D are " +"holes, so the list node cannot be combined with the next A-B sequence." +msgstr "" +"FreeBSD 3.X использует \"последовательный список свободных областей\" для " +"управления свободными областями в разделе подкачки. Идея состоит в том, что " +"большие последовательные блоки свободного пространства могут быть " +"представлены при помощи узла односвязного списка ([.filename]#kern/" +"subr_rlist.c#). Но из-за фрагментации последовательный список сам становится " +"фрагментированным. В примере выше полностью неиспользуемое пространство в A " +"и B будет показано как \"свободное\", а C и D как \"полностью занятое\". " +"Каждой последовательности A-B требуется для учета узел списка, потому что C " +"и D являются дырами, так что узел списка не может быть связан со следующей " +"последовательностью A-B." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:320 +msgid "" +"Why do we interleave our swap space instead of just tack swap areas onto the " +"end and do something fancier? It is a whole lot easier to allocate linear " +"swaths of an address space and have the result automatically be interleaved " +"across multiple disks than it is to try to put that sophistication elsewhere." +msgstr "" +"Почему мы организуем чередование в области подкачки вместо того, чтобы " +"просто объединить области подкачки в одно целое и придумать что-то более " +"умное? Потому что гораздо легче выделять последовательные полосы адресного " +"пространства и получать в результате автоматическое чередование между " +"несколькими дисками, чем пытаться выдумывать сложности в другом месте." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:325 +msgid "" +"The fragmentation causes other problems. Being a linear list under 3.X, and " +"having such a huge amount of inherent fragmentation, allocating and freeing " +"swap winds up being an O(N) algorithm instead of an O(1) algorithm. " +"Combined with other factors (heavy swapping) and you start getting into " +"O(N^2) and O(N^3) levels of overhead, which is bad. The 3.X system may also " +"need to allocate KVM during a swap operation to create a new list node which " +"can lead to a deadlock if the system is trying to pageout pages in a low-" +"memory situation." +msgstr "" +"Фрагментация вызывает другие проблемы. Являясь последовательным списком в " +"3.X и имея такое огромную фрагментацию, выделение и освобождение в области " +"подкачки становится алгоритмом сложности O(N), а не O(1). Вместе с другими " +"факторами (частое обращение к области подкачки) вы получаете сложность " +"уровней O(N^2) и O(N^3), что плохо. В системе 3.X также может потребоваться " +"выделение KVM во время работы с областью подкачки для создания нового узла " +"списка, что в условии нехватки памяти может привести к блокировке, если " +"система попытается сбросить страницы в область подкачки." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:330 +msgid "" +"Under 4.X we do not use a sequential list. Instead we use a radix tree and " +"bitmaps of swap blocks rather than ranged list nodes. We take the hit of " +"preallocating all the bitmaps required for the entire swap area up front but " +"it winds up wasting less memory due to the use of a bitmap (one bit per " +"block) instead of a linked list of nodes. The use of a radix tree instead " +"of a sequential list gives us nearly O(1) performance no matter how " +"fragmented the tree becomes." +msgstr "" +"В 4.X мы не используем последовательный список. Вместо этого мы используем " +"базисное дерево и битовые карты блоков области подкачки, а не ограниченный " +"список узлов. Мы принимаем предварительное выделение всех битовых карт, " +"требуемых для всей области подкачки, но при этом тратится меньше памяти, " +"потому что мы используем битовые карты (один бит на блок), а не связанный " +"список узлов. Использование базисного дерева вместо последовательного списка " +"дает нам производительность O(1) вне зависимости от фрагментации дерева." + +#. type: Title === +#: documentation/content/en/articles/vm-design/_index.adoc:331 +#, no-wrap +msgid "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 systat -vm? Do the systat stats roll the active and dirty pages together for the active queue count?" +msgstr "Как разделение чистых и грязных (неактивных) страниц связано с ситуацией, когда вы видите маленький счетчик очереди кэша и большой счетчик активной очереди в выдаче команды systat -vm? Разве системная статистика не считает активные и грязные страницы вместе за счетчик активной очереди?" + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:336 +msgid "" +"Yes, that is confusing. The relationship is \"goal\" verses \"reality\". " +"Our goal is to separate the pages but the reality is that if we are not in a " +"memory crunch, we do not really have to." +msgstr "" +"Да, это запутывает. Связь заключается в \"желаемом\" и \"действительном\". " +"Мы желаем разделить страницы, но реальность такова, что пока у нас нет " +"проблем с памятью, нам это на самом деле не нужно." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:338 +msgid "" +"What this means is that FreeBSD 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 is not being stressed, even if they are not " +"being used." +msgstr "" +"Это означает, что FreeBSD не будет очень сильно стараться над отделением " +"грязных страниц (неактивная очередь) от чистых страниц (очередь кэша), когда " +"система не находится под нагрузкой, и не будет деактивировать страницы " +"(активная очередь -> неактивная очередь), когда система не нагружена, даже " +"если они не используются." + +#. type: Title === +#: documentation/content/en/articles/vm-design/_index.adoc:339 +#, no-wrap +msgid "In man:ls[1] the / vmstat 1 example, 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?" +msgstr "В примере с / vmstat 1 могут ли некоторые ошибки доступа к странице быть ошибками страниц данных (COW из выполнимого файла в приватные страницы)? То есть я полагаю, что ошибки доступа к страницам являются частично ошибками при заполнении нулями, а частично данных программы. Или вы гарантируете, что FreeBSD выполняет предварительно COW для данных программы?" + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:345 +msgid "" +"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, but it _does_ pre-map pages that exist in its " +"cache." +msgstr "" +"Ошибка COW может быть ошибкой при заполнении нулями или данных программы. " +"Механизм в любом случае один и тот же, потому что хранилище данных программы " +"уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет " +"предварительное COW данных программы и заполнение нулями, но она _выполняет_ " +"предварительно отображение страниц, которые имеются в ее кэше." + +#. type: Title === +#: documentation/content/en/articles/vm-design/_index.adoc:346 +#, no-wrap +msgid "In your section on page table optimizations, can you give a little more detail about pv_entry and vm_page (or should vm_page be vm_pmap-as in 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of operation/reaction would require scanning the mappings?" +msgstr "В вашем разделе об оптимизации таблицы страниц, не могли бы вы более подробно рассказать о pv_entry и vm_page (или vm_page должна быть vm_pmap-как в 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? А именно какое действие/реакцию должно потребоваться для сканирования отображений?" + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:350 +msgid "" +"A `vm_page` represents an (object,index#) tuple. A `pv_entry` represents a " +"hardware page table entry (pte). If you have five processes sharing the " +"same physical page, and three of those processes's page tables actually map " +"the page, that page will be represented by a single `vm_page` structure and " +"three `pv_entry` structures." +msgstr "" +"`vm_page` представляет собой пару (object,index#). `pv_entry` является " +"записью из аппаратной таблицы страниц (pte). Если у вас имеется пять " +"процессов, совместно использующих одну и ту же физическую страницу, и в трех " +"таблицах страниц этих процессов на самом деле отображается страница, то " +"страница будет представляться одной структурой `vm_page` и тремя структурами " +"`pv_entry`." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:353 +msgid "" +"`pv_entry` structures only represent pages mapped by the MMU (one `pv_entry` " +"represents one pte). This means that when we need to remove all hardware " +"references to a `vm_page` (to reuse the page for something else, page it " +"out, clear it, dirty it, and so forth) we can simply scan the linked list of " +"pv_entry's associated with that vm_page to remove or modify the pte's from " +"their page tables." +msgstr "" +"Структуры `pv_entry` представляют страницы, отображаемые MMU (одна структура " +"`pv_entry` соответствует одной pte). Это означает, что, когда нам нужно " +"убрать все аппаратные ссылки на `vm_page` (для того, чтобы повторно " +"использовать страницу для чего-то еще, выгрузить ее, очистить, пометить как " +"грязную и так далее), мы можем просто просмотреть связный список структур " +"`pv_entry`, связанных с этой `vm_page`, для того, чтобы удалить или изменить " +"pte из их таблиц страниц." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:360 +msgid "" +"Under Linux there is no such linked list. To remove all the hardware page " +"table mappings for a `vm_page` linux must index into every VM object that " +"_might_ have mapped the page. For example, if you have 50 processes all " +"mapping the same shared library and want to get rid of page X in that " +"library, you need to 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 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 number of accesses into the page tables at the " +"same pte offset will often avoid blowing away the L1 cache line for that " +"offset, which can lead to better performance." +msgstr "" +"В Linux нет такого связного списка. Для того, чтобы удалить все отображения " +"аппаратной таблицы страниц для `vm_page`, linux должен пройти по индексу " +"каждого объекта VM, который _может_ отображать страницу. К примеру, если у " +"вас имеется 50 процессов, которые все отображают ту же самую динамическую " +"библиотеку и хотите избавиться от страницы X в этой библиотеке, то вам нужно " +"пройтись по индексу всей таблицы страниц для каждого из этих 50 процессов, " +"даже если только 10 из них на самом деле отображают страницу. Так что Linux " +"использует простоту подхода за счет производительности. Многие алгоритмы VM, " +"которые имеют сложность O(1) или (N малое) во FreeBSD, в Linux приобретают " +"сложность O(N), O(N^2) или хуже. Так как pte, представляющий конкретную " +"страницу в объекте, скорее всего, будет с тем же смещением во всех таблицах " +"страниц, в которых они отображаются, то уменьшение количества обращений в " +"таблицы страниц по тому же самому смещению часто позволяет избежать " +"разрастания кэша L1 для этого смещения, что приводит к улучшению " +"производительности." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:362 +msgid "" +"FreeBSD has added complexity (the `pv_entry` scheme) to increase performance " +"(to limit page table accesses to _only_ those pte's that need to be " +"modified)." +msgstr "" +"Во FreeBSD введены дополнительные сложности (схема с `pv_entry`) для " +"увеличения производительности (уменьшая количество обращений _только_ к тем " +"pte, которые нужно модифицировать)." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:366 +msgid "" +"But FreeBSD has a scaling problem that Linux does not in that there are a " +"limited number of `pv_entry` structures and this causes problems when you " +"have massive sharing of data. In this case you may run out of `pv_entry` " +"structures even though there is plenty of free memory available. This can " +"be fixed easily enough by bumping up the number of `pv_entry` structures in " +"the kernel config, but we really need to find a better way to do it." +msgstr "" +"Но во FreeBSD имеется проблема масштабирования, которой нет в Linux, потому " +"что имеется ограниченное число структур `pv_entry`, и это приводит к " +"возникновению проблем при большом объеме совместно используемых данных. В " +"этом случае у вас может возникнуть нехватка структур `pv_entry`, даже если " +"свободной памяти хватает. Это может быть достаточно легко исправлено " +"увеличением количества структур `pv_entry` при настройке, но на самом деле " +"нам нужно найти лучший способ делать это." + +#. type: Plain text +#: documentation/content/en/articles/vm-design/_index.adoc:369 +msgid "" +"In regards to the memory overhead of a page table verses the `pv_entry` " +"scheme: Linux uses \"permanent\" page tables that are not throw away, but " +"does not need a `pv_entry` for each potentially mapped pte. FreeBSD uses " +"\"throw away\" page tables but adds in a `pv_entry` structure for each " +"actually-mapped pte. I think memory utilization winds up being about the " +"same, giving FreeBSD an algorithmic advantage with its ability to throw away " +"page tables at will with very low overhead." +msgstr "" +"Что касается использования памяти под таблицу страниц против схемы с " +"`pv_entry`: Linux использует \"постоянные\" таблицы страниц, которые не " +"сбрасываются, но ему не нужны `pv_entry` для каждого потенциально " +"отображаемого pte. FreeBSD использует \"сбрасываемые\" таблицы страниц, но " +"для каждого реально отображаемого pte добавляется структура `pv_entry`. Я " +"думаю, что использование памяти будет примерно одинакова, тем более что у " +"FreeBSD есть алгоритмическое преимущество, заключающееся в способности " +"сбрасывать таблицы страниц с очень малыми накладными расходами." |