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

27 changes 29 changes 0 changes 2 changes 0 changes 53 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 2 changes 3 changes 0 changes 101 changes 100 changes 2 changes 107 changes 2 changes 190 changes 0 changes 0 changes 0 changes
Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun

Quick numbers

107 k
Hosted words
1,598
Hosted strings
15%
Translated
1
Contributors
and previous 30 days

Trends of last 30 days

+5%
Hosted words
+100%
+5%
Hosted strings
+100%
−1%
Translated
+16%
—
Contributors
+100%
User avatar None

Committed changes

Documentation / articles/vm-design/_index — Portuguese

Committed changes 3 weeks ago
User avatar None

New strings to translate

Documentation / articles/vm-design/_index — Portuguese

94 new strings to translate appeared to the translation. 3 weeks ago
User avatar None

Resource update

Documentation / articles/vm-design/_index — Portuguese

File documentation/content/pt/articles/vm-design/_index.po was added. 3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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).
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
User avatar None

String updated in the repository

Documentation / articles/vm-design/_index — Portuguese

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.
 
3 weeks ago
Browse all component changes