Oversettelsesstatus

82 Strenger 100%
Bla gjennom Oversett
5 388 Ord 100%

Strengstatus

82
Alle strenger — 5 388 ord Bla gjennom Oversett Zen
82
Oversatte strenger — 5 388 ord Bla gjennom Oversett Zen
2
Oversatte strenger med avviste kontroller — 222 ord Bla gjennom Oversett Zen
82
Strenger uten etikett — 5 388 ord Bla gjennom Oversett Zen

Andre komponenter

Komponent Oversatt Uferdig Uferdige ord Uferdige tegn Ikke oversatt Kontroller Forslag Kommentarer
books/developers-handbook/book Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
articles/contributing/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
articles/fonts/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
books/developers-handbook/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
books/handbook/partiii Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
books/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
articles/cups/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
books/fdp-primer/working-copy/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
articles/new-users/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
books/handbook/filesystems/_index Komponenten er lenket til Documentation/articles/bsdl-gpl-kodelageret. BSD-2-Clause 0 0 0 0 0 0 0
Bla gjennom alle komponenter

Oversikt

Prosjektnettsted docs.freebsd.org/en
Oversettelseslisens BSD 2-Clause "Simplified" License
Oversettelsesprosess
  • Oversettelser kan gjøres direkte.
  • Oversettelsesforslag kan sendes inn.
  • Kun utvalgte brukere kan bidra.
  • Oversettelsen bruker flerspråklige filer.
Filmaske documentation/content/*/articles/vm-design/_index.po
Oversettelsesfil Last ned documentation/content/ru/articles/vm-design/_index.po
Siste endring 4. mars 2026 17:02
Siste forfatter Vladlen Popolitov

Strengstatistikk

Strings percent Vertslagrede strenger Words percent Vertslagrede ord Tegnprosent Vertslagrede tegn
Total 82 5 388 30 906
Oversatt 100% 82 100% 5 388 100% 30 906
Trenger redigering 0% 0 0% 0 0% 0
Skrivebeskyttet 0% 0 0% 0 0% 0
Feilende kontroller 0% 0 0% 0 0% 0
Strenger med forslag 0% 0 0% 0 0% 0
Uoversatte strenger 0% 0 0% 0 0% 0
Siste 12 måneder Previous

Aktivitet siste 12 måneder

0 endringer 0 endringer 0 endringer 0 endringer 0 endringer 101 endringer 0 endringer 10 endringer 0 endringer 81 endringer 0 endringer 0 endringer 0 endringer 0 endringer 0 endringer 0 endringer 0 endringer 24 endringer 0 endringer 0 endringer 0 endringer 0 endringer 0 endringer 0 endringer
Mar Apr Mai Jun Jul Aug Sep Okt Nov Des Jan Feb

Hurtignumre

5 388
Vertslagrede ord
82
Vertslagrede strenger
100%
Oversatt
2
Bidragsytere
and previous 30 days

Trends of last 30 days

—
Vertslagrede ord
+100%
—
Vertslagrede strenger
+100%
—
Oversatt
+100%
+100%
Bidragsytere
—
Brukeravatar Ingen

Innsendte endringer

Documentation / articles/vm-design/_index — Russisk

Innsendte endringer 2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
Годами ходили современные легенды, что Linux выполняет работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом деле FreeBSD старается сбросить на диск неиспользуемые страницы для освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я не знаю, остаеётся ли это правдой на сегодняшний день.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
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 не часто бывают глубже четырёх уровней. Это так как для порождающего, так и для порожденного процессов, и остаеётся в силе как в случае, когда ветвление делает родитель, так и в случае, когда ветвление выполняет потомок.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и именно из-за академических корней BSD изначально большое внимание уделялось проработке алгоритмов. Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости кода, который может быть достаточно легко изменен, расширен или с течением времени заменен. Хотя некоторые считают BSD "старой" операционной системой, те их нас, кто работает над ней, видят её скорее системой со "зрелым" кодом с различными компонентами, которые были заменены, расширены или изменены современным кодом. Он развивается, и FreeBSD остаеётся передовой системой, вне зависимости от того, насколько старой может быть часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сделали многие другие современные операционные системы. Самым ярки примером здесь является Windows NT(R), и последствия ужасны. Linux также в некоторой степени совершил эту ошибку-достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема, которая легко и быстро решается сообществом Linux точно так же, как она решается в сообществе BSD-постоянной работой над кодом. Разработчики Windows NT(R), с другой стороны, постоянно совершают те же самые ошибки, что были решены в UNIX(R) десятки лет назад, а затем тратят годы на их устранение. Снова и снова. Есть несколько случаев "проработка архитектуры отсутствует" и "мы всегда правы, потому что так говорит наш отдел продаж". Я плохо переношу тех, кого не учит история.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
В 4.X мы не используем последовательный список. Вместо этого мы используем базисное дерево и битовые карты блоков области подкачки, а не ограниченный список узлов. Мы принимаем предварительное выделение всех битовых карт, требуемых для всей области подкачки, но при этом тратится меньше памяти, потому что мы используем битовые карты (один бит на блок), а не связанный список узлов. Использование базисного дерева вместо последовательного списка даеёт нам производительность O(1) вне зависимости от фрагментации дерева.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
Оптимизация таблицы страниц составляет самую содержательную часть архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при значительном использовании `mmap()`. Я думаю, что это на самом деле особенность работы большинства BSD-систем, хотя я не уверен, когда это проявилось впервые. Есть два основных подхода к оптимизации. Первый заключается в том, что аппаратные таблицы страниц не содержат постоянного состояния, а вместо этого могут быть сброшены в любой момент с малыми накладными расходами. Второй подход состоит в том, что каждая активная таблица страниц в системе имеет управляющую структуру `pv_entry`, которая связана в структуру `vm_page`. FreeBSD может просто просматривать эти отображения, которые существуют, когда как в Linux должны проверяться все таблицы страниц, которые _могут_ содержать нужное отображение, что в некоторых ситуация даеёт увеличение сложности O(n^2). Из-за того, что FreeBSD стремится выбрать наиболее подходящую к повторному использованию или сбросу в область подкачки страницу, когда ощущается нехватка памяти, система даеёт лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая настройка ядра для соответствия ситуациям с большим совместно используемым адресным пространством, которые могут случиться в системе, обслуживающей сервер телеконференций, потому что структуры `pv_entry` могут оказаться исчерпанными.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

Swap management structures are allocated through a hash table rather than a linear array giving them a fixed allocation size and much finer granularity.
Структуры управления областью подкачки распределяются при помощи хэш-таблицы, а не через линейный массив, что даеёт им фиксированный размер при распределении и работу с гораздо меньшими структурами.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
Самым важным аспектом при проектировании производительности является то, что называется "оптимизацией критического маршрута". Часто случается, что оптимизация производительности даеёт прирост объёма кода ради того, чтобы критический маршрут работал быстрее.
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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:
FreeBSD использует в области подкачки механизм чередования, с индексом по умолчанию, равным четырем. Это означает, что FreeBSD резервирует пространство для четыреёх областей подкачки, даже если у вас имеется всего лишь одна, две или три области. Так как в области подкачки имеется чередование, то линейное адресное пространство, представляющее "четыре области подкачки", будет фрагментироваться, если у вас нет на самом деле четыреёх областей подкачки. Например, если у вас две области A и B, то представление адресного пространства для этой области подкачки во FreeBSD будет организовано с чередованием блоков из 16 страниц:
2 dager siden
Brukeravatar v.popolitov

Søk og erstatt

Documentation / articles/vm-design/_index — Russisk

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.
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 не часто бывают глубже четыреёх уровней. Это так как для порождающего, так и для порожденного процессов, и остается в силе как в случае, когда ветвление делает родитель, так и в случае, когда ветвление выполняет потомок.
2 dager siden
Bla gjennom alle oversettelsesendringer