Pro zobrazení upozornění se prosím přihlaste.

Přehled

Stránky projektu docs.freebsd.org/en
Licence překladu BSD 2-Clause "Simplified" License
Proces překladu
  • Je možné překládat přímo.
  • Je možné dávat návrhy překladu.
  • Přispívat mohou pouze zvolení uživatelé.
  • Překlad používá dvojjazyčné soubory.
Maska souborů documentation/content/*/articles/vm-design/_index.po

Statistiky řetězců

Procento řetězců Hostovaných řetězců Procento slov Hostovaných slov Procento znaků Hostovaných znaků
Celkem 1 558 102 372 587 214
Zdrojových 82 5 388 30 906
Přeložených 19 % 309 16 % 16 457 16 % 94 673
Potřebuje upravit 3 % 50 4 % 4 737 4 % 27 041
Pouze ke čtení 5 % 82 5 % 5 388 5 % 30 906
Selhavší kontroly 2 % 41 3 % 3 871 3 % 22 150
Řetězce s návrhy 1 % 5 1 % 208 1 % 1 197
Nepřeložené řetězce 76 % 1 199 79 % 81 178 79 % 465 500
Posledních 12 měsíců Předchozích

Aktivita za posledních 12 měsíců

2 změny 1 změna 0 změn 101 změn 0 změn 69 změn 97 změn 84 změn 0 změn 2 změny 0 změn 0 změn 0 změn 0 změn 0 změn 24 změn 0 změn 0 změn 97 změn 0 změn 0 změn 0 změn 0 změn 60 změn
Dub Kvě Čer Čec Srp Zář Říj Lis Pro Led Úno Bře

Rychlá čísla

102 k
Hostovaných slov
1 558
Hostovaných řetězců
19 %
Přeloženo
3
Přispěvatelé
a předchozích 30 dní

Trendy posledních 30 dní

—
Hostovaných slov
+100 %
—
Hostovaných řetězců
+100 %
+1 %
Přeloženo
+19 %
+100 %
Přispěvatelé
—
Avatar uživatele Žádný

Zapsány změny

Documentation / articles/vm-design/_index — Ruština

Zapsány změny před 10 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Такая модель создаёт некоторое количество потенциальных проблем. Во-первых, можно получить относительно глубокий стек наслоённых объектов виртуальной памяти, что может увеличить время сканирования и расход памяти при обработке страничного исключения. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются ещё раз (как порождённые, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мёртвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем последнем примере, если каки родитель, так и потомок изменяют одну и ту же страницу, они оба получают собственные копии страницы, а исходная страница на уровне **B** становится никому не доступнойедоступной ни для одного из них. Такая страница в **B** может быть высвобождена.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
FreeBSD использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во FreeBSD являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего её процесса. После того, как подходящая страница, на основе счеётчика использования, выбрана, именно это и выполняется. Система должна различать чистые страницы, которые теоретически могут быть высвобождены в любое время, и грязные страницы, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы страничными нарушениями VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается "высвобождать немедленно" и повторно использовать в LRU-порядке (наименее давно используемый), когда системе потребуется выделение дополнительной памяти.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения неверно выбранной страницы? Каждый неправильный выбор будет стоить нам сотени тысяч тактов работы центрального процессора и заметноего замедлениея работы затронутых процессов, так что мы должны смириться со значительными издержками дляради того, чтобы была выбрана правильная страница. Вот почему FreeBSD превосходит другие системы в производительности при нехватке ресурсов памяти.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения не тверно выбранной страницы? Каждый неправильный выбор будет стоить нам сотни тысяч тактов работы центрального процессора и заметное замедление работы затронутых процессов, так что мы должны смириться со значительными издержками для того, чтобы была выбрана правильная страница. Вот почему FreeBSD превосходит другие системы в производительности при нехватке ресурсов памяти.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Во FreeBSD 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет собой целый объект, требующий хранения в области подкачки — даже если только несколько страниц этого объекта хранятся в области подкачки. Это создаёт проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объём памяти при работе (RSS).
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Проблема с мёртвой страницей все ещё имеет место, когда *C1* или *C2* не полностью перекрывают *B*. Из-за других применяемых нами методов оптимизации этот случай не представляет большой проблемы, и мы просто позволяем таким страницам существовать. Если система испытывает нехватку оперативной памяти, она выполняет их выгрузку в область подкачки, что занимает некоторое пространство в области подкачки, но это всё.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
Страничное нарушение COW может быть связано или с заполнениием нулями, или с данныхми программы. Механизм в любом случае один и тот же, потому что хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет предварительное COW данных программы и заполнение нулями, но она _выполняет_ предварительно отображение страниц, которые имеются в её кэше.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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.
ОшибкаСтраничное нарушение COW может быть ошибкой прили заполнении нулями или данных программы. Механизм в любом случае один и тот же, потому что хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет предварительное COW данных программы и заполнение нулями, но она _выполняет_ предварительно отображение страниц, которые имеются в её кэше.
před 11 dny
Avatar uživatele v.popolitov

Změna překladu

Documentation / articles/vm-design/_index — Ruština

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?
В примере с man:ls(1) и `vmstat 1` выше могут ли некоторые страничные нарушения быть страничными нарушениями данных (COW из выполнимого файла в приватные страницы)? То есть я полагаю, что ошибки доступа к страницам являются частично ошибками приИными словами, я ожидаю, что часть страничных нарушений будет связана с заполнениием нулями, а частично данных программыь — с программными данными. Или вы гарантируете, что FreeBSD выполняет предварительно COW для данных программы?
před 11 dny
Procházet všechny změny v součásti