Documentation/articles/vm-design/

Language	Translated	Unfinished	Unfinished words	Unfinished characters	Untranslated	Checks	Suggestions	Comments
English BSD-2-Clause		0	0	0	0	1	0	0

Chinese (Simplified) (zh_CN) BSD-2-Clause	4%	90	6,344	36,572	90	0	0	0

Chinese (Traditional) (zh_TW) BSD-2-Clause	4%	90	6,344	36,572	90	0	0	0

Dutch (nl_NL) BSD-2-Clause	2%	92	6,346	36,583	92	1	0	0

French (fr_FR) BSD-2-Clause	2%	92	6,346	36,590	92	0	0	0

German (de_DE) BSD-2-Clause	4%	90	6,344	36,572	90	0	0	0

Greek BSD-2-Clause	3%	91	6,345	36,582	91	0	0	0

Indonesian BSD-2-Clause	3%	91	6,345	36,582	91	0	0	0

Italian (it_IT) BSD-2-Clause	4%	90	6,344	36,572	90	0	0	0

Korean BSD-2-Clause	5%	89	6,330	36,492	89	0	0	0

Norwegian Bokmål BSD-2-Clause	2%	92	6,346	36,583	92	0	0	0

Persian BSD-2-Clause	3%	91	6,345	36,582	91	0	0	0

Polish BSD-2-Clause	4%	90	6,344	36,572	90	0	0	0

Portuguese BSD-2-Clause	0%	94	6,348	36,605	94	0	0	0

Portuguese (Brazil) BSD-2-Clause	21%	74	6,085	34,941	14	51	5	0

Spanish BSD-2-Clause		0	0	0	0	0	0	0

Turkish (tr_TR) BSD-2-Clause	0%	94	6,348	36,605	94	0	0	0

Please sign in to see the alerts.

Overview

Project website	docs.freebsd.org/en
Translation license	BSD 2-Clause "Simplified" License
Translation process	Translations can be made directly. Translation suggestions can be made. Only chosen users can contribute. The translation uses bilingual files.
File mask	`documentation/content/*/articles/vm-design/_index.po`

String statistics

	Strings percent	Hosted strings	Words percent	Hosted words	Characters percent	Hosted characters
Total		1,598		107,916		622,285
Source		94		6,348		36,605
Translated	15%	248	12%	13,012	12%	75,280
Needs editing	3%	60	5%	5,626	5%	32,333
Read-only	5%	94	5%	6,348	5%	36,605
Failing checks	3%	53	4%	4,859	4%	27,976
Strings with suggestions	1%	5	1%	208	1%	1,197
Untranslated strings	80%	1,290	82%	89,278	82%	514,672

Last 12 months Previous

Activity in last 12 months


Nov	Dec	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct

Quick numbers

107 k

Hosted words

1,598

Hosted strings

15%

Translated

Contributors

and previous 30 days

Trends of last 30 days

—

Hosted words

+100%

—

Hosted strings

+100%

—

Translated

+15%

—

Contributors

—

Search

Advanced query builder

Query examples

Review strings changed by other users	`changed:>=2024-10-21 AND NOT changed_by:anonymous`	Add
Translated strings	`state:>=translated`	Add
Strings with comments	`has:comment`	Add
Strings with any failing checks	`has:check`	Add
Strings with suggestions from others	`has:suggestion AND NOT suggestion_author:anonymous`	Add
Approved strings with suggestions	`state:approved AND has:suggestion`	Add
All untranslated strings added the past month	`added:>=2024-10-21 AND state:<=needs-editing`	Add
Translated strings in a certain language	`is:translated AND language:en`	Add

None Committed changes Documentation / articles/vm-design/_index — Portuguese	Committed changes 4 months ago
None New strings to translate Documentation / articles/vm-design/_index — Portuguese	94 new strings to translate appeared to the translation. 4 months ago
None Resource update Documentation / articles/vm-design/_index — Portuguese	File `documentation/content/pt/articles/vm-design/_index.po` was added. 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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). Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago
None String updated in the repository Documentation / articles/vm-design/_index — Portuguese	English 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. Portuguese 0 characters edited Current translation 4 months ago

Browse all component changes