The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: answer/para
English
A <literal>vm_page</literal> represents an (object,index#) tuple. A <literal>pv_entry</literal> 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 <literal>vm_page</literal> structure and three <literal>pv_entry</literal> structures.
418/3950 · 395
Context English Portuguese (Brazil) State
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 <quote>four swap areas</quote> 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: O FreeBSD usa um intercalador de swap fixo, cujo padrão é 4. Isso significa que o FreeBSD reserva espaço para quatro áreas de swap, mesmo se você tiver apenas uma, duas ou três. Como a swap é intercalada, o espaço de endereçamento linear representando as <quote>quatro áreas de troca</quote> estará fragmentado se você não tiver quatro áreas de troca. Por exemplo, se você tiver duas áreas de swap, A e B, a representação do espaço de endereçamento do FreeBSD para esta área de troca será intercalada em blocos de 16 páginas:
A B C D A B C D A B C D A B C D A B C D A B C D A B C D A B C D
FreeBSD 3.X uses a <quote>sequential list of free regions</quote> 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</filename>). 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 <quote>free</quote> and C and D shown as <quote>all allocated</quote>. 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. O FreeBSD 3.X usa uma abordagem de <quote>lista sequencial de regiões livres</quote> para contabilizar as áreas de swap livres. A ideia é que grandes blocos de espaço linear livre possam ser representados com um único nó da lista (<filename>kern/subr_rlist.c</filename>). Mas devido a fragmentação, a lista sequencial acaba sendo insanamente fragmentada. No exemplo acima, a swap completamente sem uso terá A e B mostrados como <quote>livres</quote> e C e D mostrados como <quote>todos alocados</quote>. Cada sequência A-B requer um nó da lista para considerar porque C e D são buracos, portanto, o nó de lista não pode ser combinado com a próxima sequência A-B.
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. Por que nós intercalamos nosso espaço de swap em vez de apenas colocar as áreas de swap no final e fazer algo mais sofisticado? Porque é muito mais fácil alocar trechos lineares de um espaço de endereçamento e ter o resultado automaticamente intercalado em vários discos do que tentar colocar esta sofisticação em outro lugar.
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. A fragmentação causa outros problemas. Sendo uma lista linear sob 3.X, e tendo uma enorme quantidade de fragmentação inerente, alocando e liberando swap leva a ser um algoritmo O(N) ao invés de um algoritmo O(1). Combinado com outros fatores (troca pesada) e você começa a entrar em níveis de sobrecarga O(N^2) e O(N^3), o que é ruim. O sistema 3.X também pode precisar alocar o KVM durante uma operação de troca para criar um novo nó da lista que pode levar a um impasse se o sistema estiver tentando fazer uma liberação de página em uma situação de pouca memória.
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. No 4.X, não usamos uma lista sequencial. Em vez disto, usamos uma árvore raiz e bitmaps de blocos de swap em vez de lista de nós variáveis. Aceitamos o sucesso de pré-alocar todos os bitmaps necessários para toda a área de swap na frente, mas acaba desperdiçando menos memória devido ao uso de um bitmap (um bit por bloco) em vez de uma lista encadeada de nós. O uso de uma árvore raiz em vez de uma lista sequencial nos dá quase o desempenho O(1), não importa o quão fragmentada a árvore se torne.
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 <command>systat -vm</command>? Do the systat stats roll the active and dirty pages together for the active queue count? Como a separação de páginas limpas e sujas (inativas) está relacionada à situação em que você vê baixas contagens de filas de cache e altas contagens de filas ativas no <command>systat -vm</command>? As estatísticas do systat rolam as páginas ativa e inativas juntas para a contagem de filas ativas?
I do not get the following: Eu não entendo o seguinte:
It is important to note that the FreeBSD VM system attempts to separate clean and dirty pages for the express reason of avoiding unnecessary flushes of dirty pages (which eats I/O bandwidth), nor does it move pages between the various page queues gratuitously when the memory subsystem is not being stressed. This is why you will see some systems with very low cache queue counts and high active queue counts when doing a <command>systat -vm</command> command. É importante notar que o sistema de VM do FreeBSD tenta separar páginas limpas e inativas pelo motivo expresso de evitar descargas desnecessárias de páginas inativas (que consomem largura de banda de I/O), nem mover páginas entre as várias filas de páginas gratuitamente quando subsistema de memória não está sendo estressado. É por itso que você verá alguns sistemas com contagens de fila de cache muito baixas e contagens de fila ativa altas ao executar um comando <command>systat -vm</command>.
Yes, that is confusing. The relationship is <quote>goal</quote> verses <quote>reality</quote>. 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. Sim, isto é confuso. A relação é <quote>meta</quote> versus <quote>realidade</quote>. Nosso objetivo é separar as páginas, mas a realidade é que, se não estamos em uma crise de memória, não precisamos realmente fazer isso.
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 -&gt; inactive queue) when the system is not being stressed, even if they are not being used. O que isto significa é que o FreeBSD não tentará muito separar páginas sujas (fila inativa) de páginas limpas (fila de cache) quando o sistema não está sendo estressado, nem vai tentar desativar páginas (fila ativa -&gt; fila inativa) quando o sistema não está sendo estressado, mesmo que não estejam sendo usados.
In the <citerefentry><refentrytitle>ls</refentrytitle><manvolnum>1</manvolnum></citerefentry> / <command>vmstat 1</command> 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? No exemplo <citerefentry><refentrytitle>ls</refentrytitle><manvolnum>1</manvolnum></citerefentry> / <command>vmstat 1</command>, algumas falhas de página não seriam falhas de página de dados (COW do arquivo executável para a página privada)? Ou seja, eu esperaria que as falhas de página fossem um preenchimento com zero e alguns dados do programa. Ou você está sugerindo que o FreeBSD faz pré-COW para os dados do programa?
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 <emphasis>does</emphasis> pre-map pages that exist in its cache. Uma falha de COW pode ser preenchimento com zero ou dados de programa. O mecanismo é o mesmo dos dois modos, porque os dados do programa de apoio quase certamente já estão no cache. Eu estou realmente juntando os dois. O FreeBSD não faz o pré-COW dos dados do programa ou preenchimento com zero, mas <emphasis>faz</emphasis> pré-mapeamento de páginas que existem em seu cache.
In your section on page table optimizations, can you give a little more detail about <literal>pv_entry</literal> and <literal>vm_page</literal> (or should vm_page be <literal>vm_pmap</literal>—as in 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of operation/reaction would require scanning the mappings? Em sua seção sobre otimizações de tabela de páginas, você pode dar um pouco mais de detalhes sobre <literal>pv_entry</literal> e <literal>vm_page</literal> (ou vm_page deveria ser <literal>vm_pmap</literal>- como em 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Especificamente, que tipo de operação/reação exigiria a varredura dos mapeamentos?
How does Linux do in the case where FreeBSD breaks down (sharing a large file mapping over many processes)? Como o Linux faz no caso onde o FreeBSD quebra (compartilhando um grande mapeamento de arquivos em muitos processos)?
A <literal>vm_page</literal> represents an (object,index#) tuple. A <literal>pv_entry</literal> 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 <literal>vm_page</literal> structure and three <literal>pv_entry</literal> structures. Uma <literal>vm_page</literal> representa uma tupla (objeto,índice#). Um <literal>pv_entry</literal> representa uma entrada de tabela de página de hardware (pte). Se você tem cinco processos compartilhando a mesma página física, e três dessas tabelas de páginas atualmente mapeiam a página, esta página será representada por uma única estrutura <literal>vm_page</literal> e três estruturas <literal>pv_entry</literal>.
<literal>pv_entry</literal> structures only represent pages mapped by the MMU (one <literal>pv_entry</literal> represents one pte). This means that when we need to remove all hardware references to a <literal>vm_page</literal> (in order 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 <literal>pv_entry</literal>'s associated with that <literal>vm_page</literal> to remove or modify the pte's from their page tables. As estruturas <literal>pv_entry</literal> representam apenas as páginas mapeadas pela MMU (uma <literal>pv_entry</literal> representa uma pte). Isso significa que quando precisamos remover todas as referências de hardware para uma <literal>vm_page</literal> (para reutilizar a página para outra coisa, paginar, limpar, inativar e assim por diante), podemos simplesmente escanear a lista encadeada de <literal>pv_entry</literal> associada a essa <literal>vm_page</literal> para remover ou modificar os pte's de suas tabelas de páginas.
Under Linux there is no such linked list. In order to remove all the hardware page table mappings for a <literal>vm_page</literal> linux must index into every VM object that <emphasis>might</emphasis> 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. No Linux, não existe essa lista vinculada. Para remover todos os mapeamentos de tabelas de páginas de hardware para um <literal>vm_page</literal>, o linux deve indexar em todos os objetos de VM que <emphasis>possam</emphasis> ter mapeado a página. Por exemplo, se você tiver 50 processos, todos mapeando a mesma biblioteca compartilhada e quiser se livrar da página X nessa biblioteca, será necessário indexar na tabela de páginas para cada um desses 50 processos, mesmo se apenas 10 deles realmente tiverem mapeado a página. Então, o Linux está trocando a simplicidade de seu design com o desempenho. Muitos algoritmos de VM que são O(1) ou (pequeno N) no FreeBSD acabam sendo O(N), O(N^2), ou pior no Linux. Como os pte's que representam uma determinada página em um objeto tendem a estar no mesmo offset em todas as tabelas de páginas em que estão mapeados, reduzir o número de acessos nas tabelas de páginas no mesmo pte offset evitará a linha de cache L1 para esse deslocamento, o que pode levar a um melhor desempenho.
FreeBSD has added complexity (the <literal>pv_entry</literal> scheme) in order to increase performance (to limit page table accesses to <emphasis>only</emphasis> those pte's that need to be modified). O FreeBSD adicionou complexidade (o esquema <literal>pv_entry</literal>) para aumentar o desempenho (para limitar os acessos da tabela de páginas a <emphasis>somente</emphasis> aqueles pte's que precisam ser modificados).
But FreeBSD has a scaling problem that Linux does not in that there are a limited number of <literal>pv_entry</literal> structures and this causes problems when you have massive sharing of data. In this case you may run out of <literal>pv_entry</literal> structures even though there is plenty of free memory available. This can be fixed easily enough by bumping up the number of <literal>pv_entry</literal> structures in the kernel config, but we really need to find a better way to do it. Mas o FreeBSD tem um problema de escalonamento que o Linux não possui, pois há um número limitado de estruturas <literal>pv_entry</literal> e isso causa problemas quando você tem um compartilhamento massivo de dados. Nesse caso, você pode ficar sem estruturas <literal>pv_entry</literal>, mesmo que haja bastante memória livre disponível. Isto pode ser corrigido com bastante facilidade aumentando o número de estruturas <literal>pv_entry</literal> na configuração do kernel, mas realmente precisamos encontrar uma maneira melhor de fazê-lo.
In regards to the memory overhead of a page table verses the <literal>pv_entry</literal> scheme: Linux uses <quote>permanent</quote> page tables that are not throw away, but does not need a <literal>pv_entry</literal> for each potentially mapped pte. FreeBSD uses <quote>throw away</quote> page tables but adds in a <literal>pv_entry</literal> 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. Em relação à sobrecarga de memória de uma tabela de páginas verso do esquema <literal>pv_entry</literal>: o Linux usa tabelas <quote>permanentes</quote> que não são descartadas, mas não precisa de um <literal>pv_entry</literal> para cada pte potencialmente mapeado. O FreeBSD usa tabelas de páginas <quote>throw away</quote>, mas adiciona em uma estrutura <literal>pv_entry</literal> para cada pte realmente mapeado. Eu acho que a utilização da memória acaba sendo a mesma, dando ao FreeBSD uma vantagem algorítmica com sua capacidade de jogar fora tabelas de páginas a vontade com uma sobrecarga muito baixa.
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. Finalmente, na seção de page coloring, pode ser útil descrever um pouco mais o que você quer dizer aqui. Eu não segui bem isso.
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 <emphasis>same</emphasis> 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! Você sabe como funciona um cache de memória de hardware L1? Vou explicar: Considere uma máquina com 16MB de memória principal, mas apenas 128K de cache L1. Geralmente, a maneira como este cache funciona é que cada bloco de 128K de memória principal usa o <emphasis>mesmo</emphasis> 128K de cache. Se você acessar o offset 0 na memória principal e depois deslocar 128K na memória principal, você pode acabar jogando fora os dados em cache que você leu do offset 0!
Now, I am simplifying things greatly. What I just described is what is called a <quote>direct mapped</quote> 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. Agora estou simplificando muito as coisas. O que acabei de descrever é o que é chamado de cache de memória de hardware <quote>diretamente mapeado</quote>. A maioria dos caches modernos são chamados de definição de associações de 2 vias ou definição de associações de 4 vias. A definição de associacões permite acessar até N regiões de memória diferentes que se sobrepõem à mesma memória de cache sem destruir os dados armazenados em cache anteriormente. Mas apenas N.
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. Então, se eu tenho um cache associativo de 4-way, eu posso acessar o offset 0, offset 128K, 256K e offset 384K e ainda ser capaz de acessar o offset 0 novamente e tê-lo vindo do cache L1. Se eu, então, acessar o deslocamento 512K, no entanto, um dos quatro objetos de dados armazenados anteriormente em cache será descartado pelo cache.
It is extremely important… <emphasis>extremely</emphasis> 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 <emphasis>hundreds</emphasis> 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 <emphasis>slow</emphasis>, when compared to the speed of a modern processor core. É extremamente importante… <emphasis>extremamente</emphasis> importante para que a maioria dos acessos de memória de um processador possam vir do cache L1, porque o cache L1 opera na frequência do processador. No momento em que você tem uma falha de cache L1 e precisa ir para o cache L2 ou para a memória principal, o processador irá parar e potencialmente sentar-se por <emphasis>centenas</emphasis> de instruções aguardando uma leitura de memória principal para completar. A memória principal (o ram dinâmico que você coloca em um computador) é <emphasis>lenta</emphasis>, quando comparada à velocidade de um núcleo de processador moderno.
Ok, so now onto page coloring: All modern memory caches are what are known as <emphasis>physical</emphasis> 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. Ok, agora em page coloring: Todos os caches de memória modernos são conhecidos como caches <emphasis>físicos</emphasis>. Eles armazenam em cache endereços de memória física, não endereços de memória virtual. Isto permite que o cache seja deixado sozinho em uma opção de contexto de processo, o que é muito importante.
But in the <trademark class="registered">UNIX</trademark> 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 <emphasis>physical</emphasis> 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 <emphasis>physical</emphasis> memory. Mas no mundo <trademark class="registered">UNIX</trademark> você está lidando com espaços de endereço virtual, não com espaços de endereço físico. Qualquer programa que você escreva verá o espaço de endereço virtual dado a ele. As páginas reais <emphasis>físicas</emphasis> subjacentes a este espaço de endereço virtual não são necessariamente contíguas fisicamente! De fato, você pode ter duas páginas que estão lado a lado em um espaço de endereço de processos que termina no offset 0 e desloca 128K na memória <emphasis>física</emphasis>.
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). Um programa normalmente pressupõe que duas páginas lado a lado serão armazenadas em cache de maneira ideal. Ou seja, você pode acessar objetos de dados em ambas as páginas sem que elas descartem a entrada de cache uma da outra. Mas isso só é verdadeiro se as páginas físicas subjacentes ao espaço de endereço virtual forem contíguas (no que se refere ao cache).
This is what Page coloring does. Instead of assigning <emphasis>random</emphasis> physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns <emphasis>reasonably-contiguous</emphasis> 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. É isso que o disfarce de página faz. Em vez de atribuir páginas físicas <emphasis>aleatórias</emphasis> a endereços virtuais, o que pode resultar em desempenho de cache não ideal, o disfarce de página atribui páginas físicas <emphasis>razoavelmente contíguas</emphasis> a endereços virtuais. Assim, os programas podem ser escritos sob a suposição de que as características do cache de hardware subjacente são as mesmas para seu espaço de endereço virtual, como seriam se o programa tivesse sido executado diretamente em um espaço de endereço físico.
Note that I say <quote>reasonably</quote> contiguous rather than simply <quote>contiguous</quote>. 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 <emphasis>not</emphasis> 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. Note que eu digo <quote>razoavelmente</quote> contíguo ao invés de simplesmente <quote>contíguo</quote>. Do ponto de vista de um cache mapeado direto de 128K, o endereço físico 0 é o mesmo que o endereço físico 128K. Assim, duas páginas lado a lado em seu espaço de endereço virtual podem acabar sendo compensadas em 128K e compensadas em 132K na memória física, mas também podem ser facilmente compensadas em 128K e compensadas em 4K na memória física e ainda manter as mesmas características de desempenho de cache. Portanto, disfarce de página <emphasis>não </emphasis> tem que atribuir páginas verdadeiramente contíguas de memória física a páginas contíguas de memória virtual, basta certificar-se de atribuir páginas contíguas do ponto de vista do desempenho e da operação do cache.

Loading…

User avatar None

New source string

FreeBSD Doc / articles_vm-design — Portuguese (Brazil)

New source string a year ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: answer/para
Source string location
article.translate.xml:758
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/vm-design.po, string 93