Units
Translation components API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/translations/documentation/articlesvm-design_index/zh_CN/units/?format=api&page=2
{ "count": 94, "next": null, "previous": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/units/?format=api", "results": [ { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "We will end with the page coloring optimizations. Page coloring is a performance optimization designed to ensure that accesses to contiguous pages in virtual memory make the best use of the processor cache. In ancient times (i.e. 10+ years ago) processor caches tended to map virtual memory rather than physical memory. This led to a huge number of problems including having to clear the cache on every context switch in some cases, and problems with data aliasing in the cache. Modern processor caches map physical memory precisely to solve those problems. This means that two side-by-side pages in a processes address space may not correspond to two side-by-side pages in the cache. In fact, if you are not careful side-by-side pages in virtual memory could wind up using the same page in the processor cache-leading to cacheable data being thrown away prematurely and reducing CPU performance. This is true even with multi-way set-associative caches (though the effect is mitigated somewhat)." ], "previous_source": "", "target": [ "" ], "id_hash": 5700219517434259076, "content_hash": 5700219517434259076, "location": "documentation/content/en/articles/vm-design/_index.adoc:297", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 61, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 160, "source_unit": "https://translate-dev.freebsd.org/api/units/615425/?format=api", "priority": 100, "id": 707460, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=cf1b3f73366ae684", "url": "https://translate-dev.freebsd.org/api/units/707460/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.025148Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "FreeBSD's memory allocation code implements page coloring optimizations, which means that the memory allocation code will attempt to locate free pages that are contiguous from the point of view of the cache. For example, if page 16 of physical memory is assigned to page 0 of a process's virtual memory and the cache can hold 4 pages, the page coloring code will not assign page 20 of physical memory to page 1 of a process's virtual memory. It would, instead, assign page 21 of physical memory. The page coloring code attempts to avoid assigning page 20 because this maps over the same cache memory as page 16 and would result in non-optimal caching. This code adds a significant amount of complexity to the VM memory allocation subsystem as you can well imagine, but the result is well worth the effort. Page Coloring makes VM memory as deterministic as physical memory in regards to cache performance." ], "previous_source": "", "target": [ "" ], "id_hash": -4289767702818845546, "content_hash": -4289767702818845546, "location": "documentation/content/en/articles/vm-design/_index.adoc:304", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 62, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 155, "source_unit": "https://translate-dev.freebsd.org/api/units/615427/?format=api", "priority": 100, "id": 707461, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=4477af00a08a0c96", "url": "https://translate-dev.freebsd.org/api/units/707461/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.112353Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Conclusion" ], "previous_source": "", "target": [ "结论" ], "id_hash": -438954553492005104, "content_hash": -438954553492005104, "location": "documentation/content/en/articles/vm-design/_index.adoc:306", "context": "", "note": "type: Title ==", "flags": "no-wrap", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 63, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 1, "source_unit": "https://translate-dev.freebsd.org/api/units/368063/?format=api", "priority": 100, "id": 707462, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=79e88528c6919f10", "url": "https://translate-dev.freebsd.org/api/units/707462/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.129890Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -2528742712089608106, "content_hash": -2528742712089608106, "location": "documentation/content/en/articles/vm-design/_index.adoc:311", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 64, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 71, "source_unit": "https://translate-dev.freebsd.org/api/units/615429/?format=api", "priority": 100, "id": 707463, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=5ce819e6b58a8056", "url": "https://translate-dev.freebsd.org/api/units/707463/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.147660Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Bonus QA session by Allen Briggs" ], "previous_source": "", "target": [ "" ], "id_hash": -3193954519288190759, "content_hash": -3193954519288190759, "location": "documentation/content/en/articles/vm-design/_index.adoc:313", "context": "", "note": "type: Title ==", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 65, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 6, "source_unit": "https://translate-dev.freebsd.org/api/units/368067/?format=api", "priority": 100, "id": 707464, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=53accb497912e8d9", "url": "https://translate-dev.freebsd.org/api/units/707464/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.155935Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "What is the interleaving algorithm that you refer to in your listing of the ills of the FreeBSD 3.X swap arrangements?" ], "previous_source": "", "target": [ "" ], "id_hash": -648622040058245068, "content_hash": -648622040058245068, "location": "documentation/content/en/articles/vm-design/_index.adoc:315", "context": "", "note": "type: Title ===", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 66, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 21, "source_unit": "https://translate-dev.freebsd.org/api/units/368069/?format=api", "priority": 100, "id": 707465, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=76ffa1b0ecd6d034", "url": "https://translate-dev.freebsd.org/api/units/707465/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.172648Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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:" ], "previous_source": "", "target": [ "" ], "id_hash": 2352136694481216650, "content_hash": 2352136694481216650, "location": "documentation/content/en/articles/vm-design/_index.adoc:321", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 67, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 81, "source_unit": "https://translate-dev.freebsd.org/api/units/615431/?format=api", "priority": 100, "id": 707466, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=a0a477dc89b6e48a", "url": "https://translate-dev.freebsd.org/api/units/707466/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.225469Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "A B C D A B C D A B C D A B C D\n" ], "previous_source": "", "target": [ "" ], "id_hash": 922062017217951916, "content_hash": 922062017217951916, "location": "documentation/content/en/articles/vm-design/_index.adoc:324", "context": "", "note": "type: delimited block . 4", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 68, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 16, "source_unit": "https://translate-dev.freebsd.org/api/units/368073/?format=api", "priority": 100, "id": 707467, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=8ccbd284f527f8ac", "url": "https://translate-dev.freebsd.org/api/units/707467/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.264852Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 5525637408233093798, "content_hash": 5525637408233093798, "location": "documentation/content/en/articles/vm-design/_index.adoc:331", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 69, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 100, "source_unit": "https://translate-dev.freebsd.org/api/units/615433/?format=api", "priority": 100, "id": 707468, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ccaf01f25b57faa6", "url": "https://translate-dev.freebsd.org/api/units/707468/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.305879Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -5189863536442483307, "content_hash": -5189863536442483307, "location": "documentation/content/en/articles/vm-design/_index.adoc:333", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 70, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/368077/?format=api", "priority": 100, "id": 707469, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=37f9e69c5597dd95", "url": "https://translate-dev.freebsd.org/api/units/707469/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.319017Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -7933960118181456140, "content_hash": -7933960118181456140, "location": "documentation/content/en/articles/vm-design/_index.adoc:338", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 71, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 92, "source_unit": "https://translate-dev.freebsd.org/api/units/615435/?format=api", "priority": 100, "id": 707470, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=11e4e94ef5ad96f4", "url": "https://translate-dev.freebsd.org/api/units/707470/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.328243Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 4155145828883344859, "content_hash": 4155145828883344859, "location": "documentation/content/en/articles/vm-design/_index.adoc:343", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 72, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 90, "source_unit": "https://translate-dev.freebsd.org/api/units/615437/?format=api", "priority": 100, "id": 707471, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=b9aa0b1dd089addb", "url": "https://translate-dev.freebsd.org/api/units/707471/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.341797Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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?" ], "previous_source": "", "target": [ "" ], "id_hash": 3353279667003563824, "content_hash": 3353279667003563824, "location": "documentation/content/en/articles/vm-design/_index.adoc:344", "context": "", "note": "type: Title ===", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 73, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 45, "source_unit": "https://translate-dev.freebsd.org/api/units/368083/?format=api", "priority": 100, "id": 707472, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ae893e1738499f30", "url": "https://translate-dev.freebsd.org/api/units/707472/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.356635Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -460051008278140723, "content_hash": -460051008278140723, "location": "documentation/content/en/articles/vm-design/_index.adoc:349", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 74, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 36, "source_unit": "https://translate-dev.freebsd.org/api/units/615439/?format=api", "priority": 100, "id": 707473, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=799d920ba10568cd", "url": "https://translate-dev.freebsd.org/api/units/707473/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.378904Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -5926730276734892911, "content_hash": -5926730276734892911, "location": "documentation/content/en/articles/vm-design/_index.adoc:351", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 75, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 56, "source_unit": "https://translate-dev.freebsd.org/api/units/368087/?format=api", "priority": 100, "id": 707474, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=2dc00636e7aa0491", "url": "https://translate-dev.freebsd.org/api/units/707474/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.396109Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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?" ], "previous_source": "", "target": [ "" ], "id_hash": 7433035198401274017, "content_hash": 7433035198401274017, "location": "documentation/content/en/articles/vm-design/_index.adoc:352", "context": "", "note": "type: Title ===", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 76, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 53, "source_unit": "https://translate-dev.freebsd.org/api/units/368089/?format=api", "priority": 100, "id": 707475, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=e72772218baee0a1", "url": "https://translate-dev.freebsd.org/api/units/707475/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.414682Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 4210968952427581281, "content_hash": 4210968952427581281, "location": "documentation/content/en/articles/vm-design/_index.adoc:358", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 77, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 52, "source_unit": "https://translate-dev.freebsd.org/api/units/615441/?format=api", "priority": 100, "id": 707476, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ba705df399a50f61", "url": "https://translate-dev.freebsd.org/api/units/707476/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.432692Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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?" ], "previous_source": "", "target": [ "" ], "id_hash": -131807252796287441, "content_hash": -131807252796287441, "location": "documentation/content/en/articles/vm-design/_index.adoc:359", "context": "", "note": "type: Title ===", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 78, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 43, "source_unit": "https://translate-dev.freebsd.org/api/units/368093/?format=api", "priority": 100, "id": 707477, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=7e2bba007e41d62f", "url": "https://translate-dev.freebsd.org/api/units/707477/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.447957Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -6972689839131770923, "content_hash": -6972689839131770923, "location": "documentation/content/en/articles/vm-design/_index.adoc:363", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 79, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 50, "source_unit": "https://translate-dev.freebsd.org/api/units/615443/?format=api", "priority": 100, "id": 707478, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=1f3c0788c1933fd5", "url": "https://translate-dev.freebsd.org/api/units/707478/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.486734Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 3727233459493505828, "content_hash": 3727233459493505828, "location": "documentation/content/en/articles/vm-design/_index.adoc:379", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 83, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 80, "source_unit": "https://translate-dev.freebsd.org/api/units/615449/?format=api", "priority": 100, "id": 707482, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=b3b9cb156c0f8b24", "url": "https://translate-dev.freebsd.org/api/units/707482/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.635105Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -1297362570668637025, "content_hash": -1297362570668637025, "location": "documentation/content/en/articles/vm-design/_index.adoc:383", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 84, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 80, "source_unit": "https://translate-dev.freebsd.org/api/units/615451/?format=api", "priority": 100, "id": 707483, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=6dfed79d9e68849f", "url": "https://translate-dev.freebsd.org/api/units/707483/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.653861Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Finally, in the page coloring section, it might help to have a little more description of what you mean here. I did not quite follow it." ], "previous_source": "", "target": [ "" ], "id_hash": 2004629771682149064, "content_hash": 2004629771682149064, "location": "documentation/content/en/articles/vm-design/_index.adoc:384", "context": "", "note": "type: Title ===", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 85, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 26, "source_unit": "https://translate-dev.freebsd.org/api/units/368107/?format=api", "priority": 100, "id": 707484, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=9bd1e028074972c8", "url": "https://translate-dev.freebsd.org/api/units/707484/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.675815Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Do you know how an L1 hardware memory cache works? I will explain: Consider a machine with 16MB of main memory but only 128K of L1 cache. Generally the way this cache works is that each 128K block of main memory uses the _same_ 128K of cache. If you access offset 0 in main memory and then offset 128K in main memory you can wind up throwing away the cached data you read from offset 0!" ], "previous_source": "", "target": [ "" ], "id_hash": 9145909268159189302, "content_hash": 9145909268159189302, "location": "documentation/content/en/articles/vm-design/_index.adoc:389", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 86, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 76, "source_unit": "https://translate-dev.freebsd.org/api/units/615453/?format=api", "priority": 100, "id": 707485, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=feeccc05b494d136", "url": "https://translate-dev.freebsd.org/api/units/707485/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.692706Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Now, I am simplifying things greatly. What I just described is what is called a \"direct mapped\" hardware memory cache. Most modern caches are what are called 2-way-set-associative or 4-way-set-associative caches. The set-associatively allows you to access up to N different memory regions that overlap the same cache memory without destroying the previously cached data. But only N." ], "previous_source": "", "target": [ "" ], "id_hash": -7670384176450923367, "content_hash": -7670384176450923367, "location": "documentation/content/en/articles/vm-design/_index.adoc:395", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 87, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 58, "source_unit": "https://translate-dev.freebsd.org/api/units/615455/?format=api", "priority": 100, "id": 707486, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=158d523b1fdd9499", "url": "https://translate-dev.freebsd.org/api/units/707486/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.710956Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "So if I have a 4-way set associative cache I can access offset 0, offset 128K, 256K and offset 384K and still be able to access offset 0 again and have it come from the L1 cache. If I then access offset 512K, however, one of the four previously cached data objects will be thrown away by the cache." ], "previous_source": "", "target": [ "" ], "id_hash": 6568108778544654505, "content_hash": 6568108778544654505, "location": "documentation/content/en/articles/vm-design/_index.adoc:398", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 88, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 59, "source_unit": "https://translate-dev.freebsd.org/api/units/615457/?format=api", "priority": 100, "id": 707487, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=db269c227f4768a9", "url": "https://translate-dev.freebsd.org/api/units/707487/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.728369Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "It is extremely important... _extremely_ important for most of a processor's memory accesses to be able to come from the L1 cache, because the L1 cache operates at the processor frequency. The moment you have an L1 cache miss and have to go to the L2 cache or to main memory, the processor will stall and potentially sit twiddling its fingers for _hundreds_ of instructions worth of time waiting for a read from main memory to complete. Main memory (the dynamic ram you stuff into a computer) is __slow__, when compared to the speed of a modern processor core." ], "previous_source": "", "target": [ "" ], "id_hash": 6588293474859458475, "content_hash": 6588293474859458475, "location": "documentation/content/en/articles/vm-design/_index.adoc:402", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 89, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 99, "source_unit": "https://translate-dev.freebsd.org/api/units/615459/?format=api", "priority": 100, "id": 707488, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=db6e520255059fab", "url": "https://translate-dev.freebsd.org/api/units/707488/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.744363Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Ok, so now onto page coloring: All modern memory caches are what are known as _physical_ caches. They cache physical memory addresses, not virtual memory addresses. This allows the cache to be left alone across a process context switch, which is very important." ], "previous_source": "", "target": [ "" ], "id_hash": -3674260667789479117, "content_hash": -3674260667789479117, "location": "documentation/content/en/articles/vm-design/_index.adoc:406", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 90, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 43, "source_unit": "https://translate-dev.freebsd.org/api/units/615461/?format=api", "priority": 100, "id": 707489, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=4d026763c437f333", "url": "https://translate-dev.freebsd.org/api/units/707489/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.779247Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "But in the UNIX(R) world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual _physical_ pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in _physical_ memory." ], "previous_source": "", "target": [ "" ], "id_hash": -4117022287661575178, "content_hash": -4117022287661575178, "location": "documentation/content/en/articles/vm-design/_index.adoc:411", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 91, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 73, "source_unit": "https://translate-dev.freebsd.org/api/units/615463/?format=api", "priority": 100, "id": 707490, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=46dd660ad390d3f6", "url": "https://translate-dev.freebsd.org/api/units/707490/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.798035Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned)." ], "previous_source": "", "target": [ "" ], "id_hash": 4011451862088314964, "content_hash": 4011451862088314964, "location": "documentation/content/en/articles/vm-design/_index.adoc:415", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 92, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 54, "source_unit": "https://translate-dev.freebsd.org/api/units/615465/?format=api", "priority": 100, "id": 707491, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=b7ab8a37095a7054", "url": "https://translate-dev.freebsd.org/api/units/707491/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.827868Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "This is what Page coloring does. Instead of assigning _random_ physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns _reasonably-contiguous_ physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space." ], "previous_source": "", "target": [ "" ], "id_hash": -3032996817252281788, "content_hash": -3032996817252281788, "location": "documentation/content/en/articles/vm-design/_index.adoc:419", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 93, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 71, "source_unit": "https://translate-dev.freebsd.org/api/units/615467/?format=api", "priority": 100, "id": 707492, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=55e8a176d6c99244", "url": "https://translate-dev.freebsd.org/api/units/707492/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.864762Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Note that I say \"reasonably\" contiguous rather than simply \"contiguous\". From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does _not_ have to assign truly contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation." ], "previous_source": "", "target": [ "" ], "id_hash": -7053199508336451325, "content_hash": -7053199508336451325, "location": "documentation/content/en/articles/vm-design/_index.adoc:423", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 94, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 114, "source_unit": "https://translate-dev.freebsd.org/api/units/615469/?format=api", "priority": 100, "id": 707493, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=1e1e006aa7a56103", "url": "https://translate-dev.freebsd.org/api/units/707493/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-04-04T21:58:50.901282Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "An easy to follow description of the design of the FreeBSD virtual memory system" ], "previous_source": "", "target": [ "" ], "id_hash": -5212445871253427557, "content_hash": -5212445871253427557, "location": "documentation/content/en/articles/vm-design/_index.adoc:1", "context": "", "note": "type: YAML Front Matter: description", "flags": "no-wrap", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 1, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 14, "source_unit": "https://translate-dev.freebsd.org/api/units/1181040/?format=api", "priority": 100, "id": 1181050, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=37a9ac18c8fcea9b", "url": "https://translate-dev.freebsd.org/api/units/1181050/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2021-06-03T22:47:30.009021Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -8494902235450807947, "content_hash": -8494902235450807947, "location": "documentation/content/en/articles/vm-design/_index.adoc:112", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 16, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 157, "source_unit": "https://translate-dev.freebsd.org/api/units/1443560/?format=api", "priority": 100, "id": 1443571, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=0a1c0b6cbe486975", "url": "https://translate-dev.freebsd.org/api/units/1443571/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2022-07-08T06:09:48.582257Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -4192121059148506934, "content_hash": -4192121059148506934, "location": "documentation/content/en/articles/vm-design/_index.adoc:82", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 10, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 38, "source_unit": "https://translate-dev.freebsd.org/api/units/1569353/?format=api", "priority": 100, "id": 1569483, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=45d2981b8604d8ca", "url": "https://translate-dev.freebsd.org/api/units/1569483/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.658877Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -4072780474139688110, "content_hash": -4072780474139688110, "location": "documentation/content/en/articles/vm-design/_index.adoc:191", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 34, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 44, "source_unit": "https://translate-dev.freebsd.org/api/units/1569355/?format=api", "priority": 100, "id": 1569484, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=477a93bcbec1c352", "url": "https://translate-dev.freebsd.org/api/units/1569484/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.661090Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 7931565045898444070, "content_hash": 7931565045898444070, "location": "documentation/content/en/articles/vm-design/_index.adoc:202", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 42, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 48, "source_unit": "https://translate-dev.freebsd.org/api/units/1569357/?format=api", "priority": 100, "id": 1569485, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ee129462d1ae7d26", "url": "https://translate-dev.freebsd.org/api/units/1569485/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.662163Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 7837563792822788789, "content_hash": 7837563792822788789, "location": "documentation/content/en/articles/vm-design/_index.adoc:205", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 44, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 46, "source_unit": "https://translate-dev.freebsd.org/api/units/1569359/?format=api", "priority": 100, "id": 1569486, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ecc49ebe8faa62b5", "url": "https://translate-dev.freebsd.org/api/units/1569486/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.662900Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -1660761811070994024, "content_hash": -1660761811070994024, "location": "documentation/content/en/articles/vm-design/_index.adoc:215", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 47, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 74, "source_unit": "https://translate-dev.freebsd.org/api/units/1569361/?format=api", "priority": 100, "id": 1569487, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=68f3c9ee92943998", "url": "https://translate-dev.freebsd.org/api/units/1569487/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.663707Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": 5780403638740543814, "content_hash": 5780403638740543814, "location": "documentation/content/en/articles/vm-design/_index.adoc:247", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 53, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 72, "source_unit": "https://translate-dev.freebsd.org/api/units/1569363/?format=api", "priority": 100, "id": 1569488, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=d0381e7bc9816946", "url": "https://translate-dev.freebsd.org/api/units/1569488/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.664688Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -3287937168931606517, "content_hash": -3287937168931606517, "location": "documentation/content/en/articles/vm-design/_index.adoc:268", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 56, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 151, "source_unit": "https://translate-dev.freebsd.org/api/units/1569365/?format=api", "priority": 100, "id": 1569489, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=525ee690aa07300b", "url": "https://translate-dev.freebsd.org/api/units/1569489/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.665498Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "`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." ], "previous_source": "", "target": [ "" ], "id_hash": 2530387555015900761, "content_hash": 2530387555015900761, "location": "documentation/content/en/articles/vm-design/_index.adoc:366", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 80, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 68, "source_unit": "https://translate-dev.freebsd.org/api/units/1569367/?format=api", "priority": 100, "id": 1569490, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=a31dbe1320cabe59", "url": "https://translate-dev.freebsd.org/api/units/1569490/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.667530Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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." ], "previous_source": "", "target": [ "" ], "id_hash": -6410095001383200919, "content_hash": -6410095001383200919, "location": "documentation/content/en/articles/vm-design/_index.adoc:373", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 81, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 171, "source_unit": "https://translate-dev.freebsd.org/api/units/1569369/?format=api", "priority": 100, "id": 1569491, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=270ac48ef20c1769", "url": "https://translate-dev.freebsd.org/api/units/1569491/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.668218Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "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)." ], "previous_source": "", "target": [ "" ], "id_hash": 2794379834289832262, "content_hash": 2794379834289832262, "location": "documentation/content/en/articles/vm-design/_index.adoc:375", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 82, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 24, "source_unit": "https://translate-dev.freebsd.org/api/units/1569371/?format=api", "priority": 100, "id": 1569492, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=a6c7a1a76e5c4146", "url": "https://translate-dev.freebsd.org/api/units/1569492/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-05-21T18:04:59.668962Z" }, { "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/zh_CN/?format=api", "source": [ "Matthew Dillon <dillon@apollo.backplane.com>" ], "previous_source": "", "target": [ "" ], "id_hash": 3328405665575463437, "content_hash": 3328405665575463437, "location": "documentation/content/en/articles/vm-design/_index.adoc:46", "context": "", "note": "type: Plain text", "flags": "", "labels": [], "state": 0, "fuzzy": false, "translated": false, "approved": false, "position": 4, "has_suggestion": false, "has_comment": false, "has_failing_check": false, "num_words": 3, "source_unit": "https://translate-dev.freebsd.org/api/units/1598414/?format=api", "priority": 100, "id": 1598427, "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/zh_CN/?checksum=ae30df517505ea0d", "url": "https://translate-dev.freebsd.org/api/units/1598427/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2023-09-09T21:51:25.670463Z" } ] }