Index: head/pt_BR.ISO8859-1/articles/Makefile =================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile (revision 52251) +++ head/pt_BR.ISO8859-1/articles/Makefile (revision 52252) @@ -1,32 +1,33 @@ # # The FreeBSD Documentation Project # The FreeBSD Brazilian Portuguese Documentation Project # # $FreeBSD$ SUBDIR = SUBDIR+= building-products SUBDIR+= contributing SUBDIR+= cups SUBDIR+= explaining-bsd SUBDIR+= fonts SUBDIR+= freebsd-questions SUBDIR+= freebsd-update-server SUBDIR+= hubs SUBDIR+= ipsec-must SUBDIR+= ldap-auth SUBDIR+= leap-seconds SUBDIR+= linux-emulation SUBDIR+= linux-users SUBDIR+= mailing-list-faq SUBDIR+= nanobsd SUBDIR+= new-users SUBDIR+= port-mentor-guidelines SUBDIR+= pr-guidelines SUBDIR+= problem-reports SUBDIR+= rc-scripting SUBDIR+= remote-install SUBDIR+= solid-state +SUBDIR+= vm-design DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Index: head/pt_BR.ISO8859-1/articles/vm-design/Makefile =================================================================== --- head/pt_BR.ISO8859-1/articles/vm-design/Makefile (nonexistent) +++ head/pt_BR.ISO8859-1/articles/vm-design/Makefile (revision 52252) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: VM Design + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Property changes on: head/pt_BR.ISO8859-1/articles/vm-design/Makefile ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: head/pt_BR.ISO8859-1/articles/vm-design/article.xml =================================================================== --- head/pt_BR.ISO8859-1/articles/vm-design/article.xml (nonexistent) +++ head/pt_BR.ISO8859-1/articles/vm-design/article.xml (revision 52252) @@ -0,0 +1,343 @@ + + + + +
+ Elementos de design do sistema de VM do FreeBSD + + + + MatthewDillon
+ dillon@apollo.backplane.com +
+ + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + Linux is a registered trademark of Linus Torvalds. + Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. + Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. + + + $FreeBSD$ + + $FreeBSD$ + + + O título é realmente apenas uma maneira extravagante de dizer que vou tentar descrever todo o grupo de itens de uma VM, espero que de uma forma que todos possam acompanhar. Pelo ultimo ano eu me concentrei em vários dos principais subsistemas do kernel dentro do FreeBSD, com os subsistemas VM e Swap sendo os mais interessantes e o NFS sendo uma tarefa necessária. Eu reescrevi apenas pequenas partes do código. Na área de VM, a única grande reescrita que fiz foi para o subsistema de troca. A maior parte do meu trabalho foi de limpeza e manutenção, com apenas uma moderada reescrita de código e sem grandes ajustes nos algorítimos do subsistema VM. A maior parte da base teórica do subsistema VM permanece inalterada e muito do crédito pelo esforço de modernização nos últimos anos pertence a John Dyson e David Greenman. Não sendo um historiador como Kirk, eu não tentarei marcar todos os vários recursos com nomes de pessoas, já que invariavelmente vou errar. + + + + Este artigo foi publicado originalmente na edição de janeiro de 2000 do DaemonNews. Esta versão do artigo pode incluir atualizações feitas por Matt e outros autores para refletir as mudanças na implementação da VM do FreeBSD. + + + + + Introdução + + Antes de avançarmos para o design atual, vamos dedicar um pouco de tempo a necessidade de manter e modernizar qualquer base de código duradoura. No mundo da programação, os algoritmos tendem a ser mais importantes do que o código, e é precisamente devido as raízes acadêmicas do BSD que uma grande atenção foi dada ao design do algoritmo desde o início. Mais atenção ao design geralmente leva a uma base de código limpa e flexível que pode ser facilmente modificada, estendida ou substituída ao longo do tempo. Embora o BSD seja considerado um sistema operacional antigo por algumas pessoas, aqueles de nós que trabalham nele tendem a vê-lo mais como uma base de código madura que possui vários componentes modificados, estendidos, ou substituído por código moderno. Ele evoluiu e o FreeBSD está no topo, não importa quantos anos tenha o código. Esta é uma distinção importante a ser feita e infelizmente perdida para muitas pessoas. O maior erro que um programador pode cometer é não aprender com a história, e esse é precisamente o erro que muitos outros sistemas operacionais modernos cometeram. Windows NT é o melhor exemplo disso, e as conseqüências foram terríveis. O Linux também cometeu esse erro até certo ponto - o suficiente para que nós, do BSD, possamos fazer pequenas piadas sobre isso de vez em quando, entretanto. O problema do Linux é simplesmente a falta de experiência e histórico para comparar idéias, um problema que está sendo resolvido de forma fácil e rápida pela comunidade Linux, da mesma forma como foi abordado na comunidade BSD - pelo desenvolvimento contínuo de código. Por outro lado, o povo do Windows NT, repetidamente comete os mesmos erros resolvidos no UNIX décadas atrás e depois gasta anos corrigindo-os. De novo e de novo. Eles têm um caso grave de não foi projetado aqui e estamos sempre certos porque nosso departamento de marketing diz que sim. Tenho pouca tolerância para quem não pode aprender com a história. + + Grande parte da complexidade aparente do design do FreeBSD, especialmente no subsistema VM/Swap, é um resultado direto de ter que resolver sérios problemas de desempenho que ocorrem sob várias condições. Estes problemas não se devem ao mau design de algorítimo, mas sim a fatores ambientais. Em qualquer comparação direta entre plataformas, estes problemas tornam-se mais aparentes quando os recursos do sistema começam a ficar estressados. Como descrevo o subsistema VM/Swap do FreeBSD, o leitor deve sempre manter dois pontos em mente: + + + + O aspecto mais importante do design de desempenho é o que é conhecido como Otimizando o Caminho Crítico . Muitas vezes, as otimizações de desempenho inflam um pouco o código, para que o caminho crítico tenha um melhor desempenho. + + + + Um design sólido e generalizado supera um projeto altamente otimizado a longo prazo. Enquanto um design generalizado pode acabar sendo mais lento do que um projeto altamente otimizado quando eles são implementados pela primeira vez, o design generalizado tende a ser mais fácil de se adaptar as mudanças de condições e o projeto altamente otimizado acaba tendo que ser descartado. + + + + Qualquer base de código que sobreviva e seja sustentável por anos deve, portanto, ser projetada adequadamente desde o início, mesmo que isso custe algum desempenho. Vinte anos atrás, as pessoas ainda argumentavam que programar em assembly era melhor do que programar em uma linguagem de alto nível porque produzia um código que era dez vezes mais rápido. Hoje, a queda desse argumento é óbvia - assim como os paralelos com o design de algorítimo e a generalização de código. + + + + Objetos de VM + + A melhor maneira de começar a descrever o sistema de VM do FreeBSD é examiná-lo da perspectiva de um processo em nível de usuário. Cada processo do usuário vê um espaço de endereço de VM único, privado e contíguo, contendo vários tipos de objetos de memória. Esses objetos possuem várias características. O código do programa e os dados do programa são efetivamente um único arquivo mapeado na memória (o arquivo binário sendo executado), mas o código do programa é read-only enquanto os dados do programa são copy-on-write. O programa BSS é apenas memória alocada e preenchida com zeros sob demanda, chamado de demanda de preenchimento de página com zero. Arquivos arbitrários também podem ser mapeados na memória dentro do espaço de endereçamento como bem entender, que é como o mecanismo de biblioteca compartilhada funciona. Esses mapeamentos podem exigir modificações para permanecerem privados para o processo que os produz. A chamada do sistema de fork adiciona uma dimensão totalmente nova ao problema de gerenciamento de VMs além da complexidade já fornecida. + + Uma página de dados binários do programa (que é uma página básica de copy-on-write) ilustra a complexidade. Um programa binário contém uma seção de dados pré-inicializada que é inicialmente mapeada diretamente a partir do arquivo de programa. Quando um programa é carregado no espaço de VM de um processo, esta área é inicialmente mapeada na memória e suportada pelo próprio binário do programa, permitindo que o sistema de VM liberte/reutilize a página e depois carregue-a de volta a partir do binário. No entanto, no momento em que um processo modifica esses dados, o sistema de VM deve fazer uma cópia privada da página para esse processo. A partir do momento que a cópia privada tenha sido modificada, o sistema de VM pode não mais liberá-la, porque não há mais como restaurá-la depois. + + Você notará imediatamente que o que originalmente era um mapeamento de arquivo simples se tornou muito mais complexo. Os dados podem ser modificados página a página, enquanto o mapeamento de arquivos abrange muitas páginas de uma só vez. A complexidade aumenta ainda mais quando existe um fork do processo. Quando um processo se duplica, o resultado são dois processos - cada um com seus próprios espaços de endereçamento privados, incluindo quaisquer modificações feitas pelo processo original antes de chamar um fork(). Seria bobagem o sistema de VM fizesse uma cópia completa dos dados no momento do fork() porque é bem possível que pelo menos um dos dois processos precise apenas ler essa página a partir de então, permitindo que a página original continue a ser usada. O que era uma página privada é feito um copy-on-write novamente, já que cada processo (pai e filho) espera que suas próprias modificações pós-fork permaneçam privadas para si mesmas e não afetem a outra. + + O FreeBSD gerencia tudo isso com um modelo de objetos de VM em camadas. O arquivo de programa binário original acaba sendo a camada de objeto de VM mais baixa. Uma camada copy-on-write é colocada acima dela para conter as páginas que tiveram que ser copiadas do arquivo original. Se o programa modificar uma página de dados pertencente ao arquivo original, o sistema de VM assumirá que existe uma falha e fará uma cópia da página na camada superior. Quando existe um fork do processo, as camadas adicionais de objetos de VM são ativadas. Isso pode fazer um pouco mais de sentido com um exemplo bastante básico. Um fork() é uma operação comum para qualquer sistema *BSD, então este exemplo irá considerar um programa que inicia e é feito um fork. Quando o processo é iniciado, o sistema de VM cria uma camada de objeto, vamos chamar isso de A: + + +---------------+ +| A | ++---------------+ A picture + + A representa o arquivo - as páginas podem ser paginadas dentro e fora da mídia física do arquivo, conforme necessário. Paginar a partir do disco é razoável para um programa, mas nós realmente não queremos voltar atrás e sobrescrever o executável. O sistema de VM, portanto, cria uma segunda camada, B, que será fisicamente suportada pelo espaço de troca: + + + + + + + + +---------------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Na primeira escrita em uma página depois disso, uma nova página é criada em B e seu conteúdo é inicializado a partir de A. Todas as páginas em B podem ser paginadas para dentro ou para fora por um dispositivo de troca. Quando é feito o fork do programa, o sistema de VM cria duas novas camadas de objetos - C1 para o processo pai e C2 para o filho - que ficam no topo de B: + + + + + + + + +-------+-------+ +| C1 | C2 | ++-------+-------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Neste caso, digamos que uma página em B seja modificada pelo processo pai original. O processo terá uma falha de copy-on-write e duplicará a página em C1, deixando a página original em B intocada. Agora, digamos que a mesma página em B seja modificada pelo processo filho. O processo assumirá uma falha de copy-on-write e duplicará a página em C2. A página original em B agora está completamente oculta, já que C1 e C2 têm uma cópia e B poderia, teoricamente, ser destruído se não representasse um arquivo real; no entanto, esse tipo de otimização não é trivial de se fazer, porque é muito refinado. O FreeBSD não faz essa otimização. Agora, suponha (como é frequentemente o caso) que o processo filho execute um exec(). Seu espaço de endereço atual é geralmente substituído por um novo espaço de endereço representando um novo arquivo. Nesse caso, a camada C2 é destruída: + + + + + + + + +-------+ +| C1 | ++-------+-------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Neste caso, o número de filhos de B cai para um, e todos os acessos para B passam agora por C1. Isso significa que B e C1 podem ser unidas. Todas as páginas em B que também existem em C1 são excluídas de B durante a união. Assim, mesmo que a otimização na etapa anterior não possa ser feita, podemos recuperar as páginas mortas quando um dos processos finalizar ou executar um exec(). + + Este modelo cria vários problemas potenciais. O primeiro é que você pode acabar com uma pilha relativamente profunda de objetos de VM em camadas, que pode custar tempo de varredura e memória quando ocorrer uma falha. Camadas profundas podem ocorrer quando houver forks dos processos e, em seguida, houver um fork novamente (do processo pai ou filho). O segundo problema é que você pode acabar com páginas profundas inacessíveis e mortas no meio da pilha de objetos de VM. Em nosso último exemplo, se os processos pai e filho modificarem a mesma página, ambos receberão suas próprias cópias privadas da página e a página original em B não poderá mais ser acessada por ninguém. Essa página em B pode ser liberada. + + O FreeBSD resolve o problema de camadas profundas com uma otimização especial chamada All Shadowed Case. Este caso ocorre se C1 ou C2 tiverem falhas de COW suficientes para fazer uma copia de sombra completa de todas as páginas em B. Digamos que C1 consiga isso. C1 agora pode ignorar B completamente, então, em vez de temos C1->B->A e C2->B->A temos agora C1->A e C2->B->A. Mas veja o que também aconteceu - agora B tem apenas uma referência (C2), então podemos unir B e C2. O resultado final é que B é deletado inteiramente e temos C1->A e C2->A. É comum que B contenha um grande número de páginas e nem C1 nem C2 possam ofuscar completamente. Se nós forçarmos novamente e criarmos um conjunto de camadas D, no entanto, é muito mais provável que uma das camadas D eventualmente seja capaz de ofuscar completamente o conjunto de dados muito menor representado por C1 ou C2. A mesma otimização funcionará em qualquer ponto do gráfico e o grande resultado disso é que, mesmo em uma máquina diversos forks, pilhas de objetos da VM tendem a não ficar muito mais profundas do que 4. Isso é verdade tanto para o processo pai quanto para os filhos e verdadeiro quer seja o processo pai fazendo o fork ou os processos filhos fazendo forks em cascata. + + O problema da página morta ainda existe no caso em que C1 ou C2 não ofuscaram completamente as páginas de B. Devido as nossas outras otimizações, este caso não representa um grande problema e simplesmente permitimos que as páginas fiquem inativas. Se o sistema ficar com pouca memória, ele irá trocá-las, comendo uma pequena parte da swap, mas é isso. + + A vantagem do modelo de objetos de VM é que o fork() é extremamente rápido, já que não é necessária nenhuma cópia de dados real. A desvantagem é que você pode criar uma camada de Objetos de VM relativamente complexa que reduz um pouco o tratamento de falhas de página e gasta memória gerenciando as estruturas de Objetos de VM. As otimizações que o FreeBSD faz prova reduzir os problemas o suficiente para que as falhas possam ser ignoradas, não deixando nenhuma desvantagem real. + + + + Camadas de SWAP + + As páginas de dados privadas são inicialmente páginas copy-on-write ou zero-fill. Quando uma alteração e, portanto, uma cópia, é feita, o objeto de apoio original (geralmente um arquivo) não pode mais ser usado para salvar uma cópia da página quando o sistema da VM precisar reutilizá-lo para outras finalidades. É aí que o SWAP entra. O SWAP é alocado para criar um suporte de armazenamento para a memória que não o possui. O FreeBSD aloca a estrutura de gerenciamento de troca para um objeto de VM somente quando for realmente necessário. No entanto, historicamente, a estrutura de gerenciamento de troca teve problemas: + + + + Sob o FreeBSD 3.X, a estrutura de gerenciamento de swap pré-aloca uma matriz que engloba todo o objeto que requer suporte para armazenamento da swap - mesmo que apenas algumas páginas desse objeto sejam suportadas por swap. Isto cria um problema de fragmentação de memória do kernel quando grandes objetos são mapeados ou processos com fork de grandes runsizes (RSS). + + + + Além disso, para manter o controle do espaço de swap, uma lista de espaços vazios é mantida na memória do kernel, e isso tende a ficar severamente fragmentado também. Como a lista de espaços vazios é uma lista linear, o desempenho de alocação e liberação de swap é uma troca O(n)-per-page (Uma por página) não ideal. + + + + Requer que as alocações de memória do kernel ocorram durante o processo de troca de swap, e isto cria problemas de deadlock de pouca memória. + + + + O problema é ainda mais exacerbado por buracos criados devido ao algoritmo de intercalação. + + + + Além disso, o mapa de blocos da swap pode se fragmentar com bastante facilidade, resultando em alocações não contíguas. + + + + A memória do kernel também deve ser alocada dinamicamente para estruturas adicionais de gerenciamento da swap quando ocorre uma troca. + + + + É evidente a partir dessa lista que havia muito espaço para melhorias. Para o FreeBSD 4.X, eu reescrevi completamente o subsistema de swap: + + + + As estruturas de gerenciamento de swap são alocadas por meio de uma tabela de hash, em vez de um array linear, fornecendo um tamanho de alocação fixo e uma granularidade muito mais fina. + + + + Em vez de usar uma lista vinculada linearmente para acompanhar as reservas de espaço de troca, ele agora usa um bitmap de blocos de troca organizados em uma estrutura de árvores raiz com dicas de espaço livre nas estruturas do nó de origem. Isto efetivamente faz a alocação de swap e libera uma operação O(1). + + + + Todo o bitmap da árvore raiz também é pré-alocado para evitar ter que alocar a memória do kernel durante operações críticas de troca com memória baixa. Afinal de contas, o sistema tende a trocar quando está com pouca memória, por isso devemos evitar a alocação da memória do kernel nesses momentos para evitar possíveis deadlocks. + + + + Para reduzir a fragmentação, a árvore raiz é capaz de alocar grandes blocos contíguos de uma só vez, pulando pedaços menores e fragmentados. + + + + Eu não dei o último passo de ter um ponteiro de sugestão de alocação que percorria uma porção da swap conforme as alocações eram feitas a fim de garantir alocações contíguas ou pelo menos a referência localmente, mas assegurei que tal adição poderia ser feita. + + + + Quando libertar uma página + + Como o sistema de VM usa toda a memória disponível para o cache em disco, geralmente há poucas páginas realmente livres. O sistema de VM depende de poder escolher corretamente as páginas que não estão em uso para reutilizar em novas alocações. Selecionar as páginas ideais para liberar é possivelmente a função mais importante que qualquer sistema de VM pode executar, porque se fizer uma seleção ruim, o sistema de VM poderá ser desnecessariamente forçado a recuperar páginas do disco, prejudicando seriamente o desempenho do sistema. + + Quanta sobrecarga estamos dispostos a sofrer no caminho crítico para evitar a liberação da página errada? Cada escolha errada que fazemos nos custará centenas de milhares de ciclos da CPU e uma paralisação notável dos processos afetados, por isto estamos dispostos a suportar uma quantidade significativa de sobrecarga, a fim de ter certeza de que a página certa é escolhida. É por isto que o FreeBSD tende a superar outros sistemas quando os recursos de memória ficam estressados. + + O algoritmo de determinação de página livre é construído sobre um histórico do uso das páginas de memória. Para adquirir este histórico, o sistema tira proveito de um recurso de um bit usado pela página que a maioria das tabelas de página de hardware possui. + + Em qualquer caso, o bit usado na página é desmarcado e, em algum momento posterior, o sistema de VM encontra a página novamente e vê que o bit usado na página foi definido. Isso indica que a página ainda está sendo usada ativamente. Se o bit ainda estiver desmarcado, é uma indicação de que a página não está sendo usada ativamente. Ao testar este bit periodicamente, é desenvolvido um histórico de uso (na forma de um contador) para a página física. Quando, posteriormente, o sistema de VM precisar liberar algumas páginas, a verificação desse histórico se tornará a base da determinação da melhor página candidata a ser reutilizada. + + + E se o hardware não tiver o bit usado na página? + + Para as plataformas que não possuem esse recurso, o sistema realmente emula um bit usado na página. Ele remove o mapeamento ou protege uma página, forçando uma falha de página se a página for acessada novamente. Quando a falha de página acontece, o sistema simplesmente marca a página como tendo sido usada e desprotege a página para que ela possa ser usada. Embora a tomada de tais falhas de página apenas para determinar se uma página está sendo usada pareça ser uma proposta cara, é muito menos dispendioso do que reutilizar a página para outra finalidade, apenas para descobrir que um processo precisa dela e depois ir para o disco . + + + O FreeBSD faz uso de várias filas de páginas para refinar ainda mais a seleção de páginas para reutilização, bem como para determinar quando páginas inativas devem ser liberadas para o suporte ao armazenamento. Como as tabelas de páginas são entidades dinâmicas sob o FreeBSD, não custa virtualmente nada desmapear uma página do espaço de endereço de qualquer processo que a utilize. Quando uma página cadidata ser escolhida com base no contador de uso de página, isso é precisamente o que é feito. O sistema deve fazer uma distinção entre páginas limpas que teoricamente podem ser liberadas a qualquer momento, e páginas inativas que devem primeiro ser escritas em seu repositório de armazenamento antes de serem reutilizáveis. Quando uma página candidata for encontrada, ela será movida para a fila inativa, se estiver inativas, ou para a fila de cache, se estiver limpa. Um algoritmo separado baseado na proporção de páginas inativas para limpas determina quando páginas inativas na fila inativa devem ser liberadas para o disco. Depois que isso for feito, as páginas liberadas serão movidas da fila inativa para a fila de cache. Neste ponto, as páginas na fila de cache ainda podem ser reativadas por uma falha de VM a um custo relativamente baixo. No entanto, as páginas na fila de cache são consideradas imediatamente livres e serão reutilizadas em uma forma LRU (usada menos recentemente) quando o sistema precisar alocar nova memória. + + É 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 move páginas entre as várias filas de páginas gratuitamente quando o subsistema de memória não está sendo enfatizado. É por isto que você verá alguns sistemas com contagens de fila de cache muito baixas e contagens alta de fila ativa ao executar um comando systat -vm. À medida que o sistema de VM se torna mais estressado, ele faz um esforço maior para manter as várias filas de páginas nos níveis determinados para serem mais eficazes. + + Uma lenda urbana circulou durante anos que o Linux fez um trabalho melhor evitando trocas do que o FreeBSD, mas isso de fato não é verdade. O que estava realmente ocorrendo era que o FreeBSD estava proativamente numerando páginas não usadas a fim de abrir espaço para mais cache de disco enquanto o Linux mantinha páginas não utilizadas no núcleo e deixando menos memória disponível para páginas de cache e processo. Eu não sei se isso ainda é verdade hoje. + + + + Otimizações de Pré-Falhas ou para Zerar + + Pegar uma falha de VM não é caro se a página subjacente já estiver no núcleo e puder simplesmente ser mapeada no processo, mas pode se tornar cara se você pegar muitas delas regularmente. Um bom exemplo disso é executar um programa como ls1 ou ps1 várias vezes. Se o programa binário é mapeado na memória, mas não mapeado na tabela de páginas, então todas as páginas que serão acessadas pelo programa irão estar com falha toda vez que o programa for executado. Isso é desnecessário quando as páginas em questão já estão no cache de VM, então o FreeBSD tentará preencher previamente as tabelas de páginas de um processo com as páginas que já estão no cache de VM. Uma coisa que o FreeBSD ainda não faz é pré-copiar-durante-escrita certas páginas no exec. Por exemplo, se você executar o programa ls1 ao executar o vmstat 1, notará que sempre pega um determinado número de falhas de página, mesmo quando você o executa várias vezes. Estas são falhas de preenchimento com zero, não falhas de código de programa (que já foram pré-falhas). A pré-cópia de páginas em exec ou fork é uma área que poderia se utilizar de mais estudos. + + Uma grande porcentagem de falhas de página que ocorrem são falhas de preenchimento com zero. Geralmente, você pode ver isso observando a saída de vmstat -s. Estas falhas ocorrem quando um processo acessa páginas em sua área BSS. Espera-se que a área BSS seja inicialmente zero, mas o sistema de VM não se preocupa em alocar memória alguma até que o processo realmente a acesse. Quando ocorre uma falha, o sistema de VM deve alocar não apenas uma nova página, mas deve zerá-la também. Para otimizar a operação de zeramento, o sistema de VM tem a capacidade de pré-zerar páginas e marcá-las como tal, e solicitar páginas pré-zeradas quando ocorrem falhas de preenchimento com zero. O pré-zeramento ocorre sempre que a CPU está inativa, mas o número de páginas que o sistema pre-zeros é limitado, a fim de evitar que os caches de memória sejam dissipados. Este é um excelente exemplo de adição de complexidade ao sistema de VM para otimizar o caminho crítico. + + + + Otimizações da Tabela de Páginas + + As otimizações da tabela de páginas constituem a parte mais contenciosa do design de VM do FreeBSD e mostraram alguma tensão com o advento do uso sério de mmap(). Eu acho que isso é realmente uma característica da maioria dos BSDs, embora eu não tenha certeza de quando foi introduzido pela primeira vez. Existem duas otimizações principais. A primeira é que as tabelas de páginas de hardware não contêm estado persistente, mas podem ser descartadas a qualquer momento com apenas uma pequena quantidade de sobrecarga de gerenciamento. A segunda é que cada entrada ativa da tabela de páginas no sistema tem uma estrutura governante pv_entry que é amarrada na estrutura vm_page. O FreeBSD pode simplesmente iterar através desses mapeamentos que são conhecidos, enquanto o Linux deve verificar todas as tabelas de páginas que possam conter um mapeamento específico para ver se ele o faz, o que pode alcançar O(n^2) situações. É por isso que o FreeBSD tende a fazer melhores escolhas em quais páginas reutilizar ou trocar quando a memória é estressada, dando-lhe melhor desempenho em sobrecarga. No entanto, o FreeBSD requer o ajuste do kernel para acomodar situações de grandes espaços de endereços compartilhados, como aquelas que podem ocorrer em um sistema de notícias, porque ele pode rodar sem estruturas pv_entry. + + Tanto o Linux quanto o FreeBSD precisam funcionar nesta área. O FreeBSD está tentando maximizar a vantagem de um modelo de mapeamento ativo potencialmente esparso (nem todos os processos precisam mapear todas as páginas de uma biblioteca compartilhada, por exemplo), enquanto o Linux está tentando simplificar seus algoritmos. O FreeBSD geralmente tem a vantagem de desempenho aqui, ao custo de desperdiçar um pouco de memória extra, mas o FreeBSD quebra no caso em que um arquivo grande é massivamente compartilhado em centenas de processos. O Linux, por outro lado, se quebra no caso em que muitos processos mapeiam esparsamente a mesma biblioteca compartilhada e também são executados de maneira não ideal ao tentar determinar se uma página pode ser reutilizada ou não. + + + + Page Coloring + + Terminaremos com as otimizações de page coloring. Page coloring é uma otimização de desempenho projetada para garantir que acessos a páginas contíguas na memória virtual façam o melhor uso do cache do processador. Nos tempos antigos (isto é, há mais de 10 anos), os caches de processador tendiam a mapear a memória virtual em vez da memória física. Isso levou a um grande número de problemas, incluindo a necessidade de limpar o cache em cada troca de contexto em alguns casos e problemas com o alias de dados no cache. Caches de processador modernos mapeiam a memória física com precisão para resolver esses problemas. Isto significa que duas páginas lado a lado em um espaço de endereço de processos podem não corresponder a duas páginas lado a lado no cache. Na verdade, se você não for cuidadoso, as páginas lado a lado na memória virtual podem acabar usando a mesma página no cache do processador - conduzindo para que dados em cache sejam descartados prematuramente e reduzindo o desempenho da CPU. Isto é verdade mesmo com caches auto associativos de múltiplas vias (embora o efeito seja um pouco mitigado). + + O código de alocação de memória do FreeBSD implementa otimizações de page coloring, o que significa que o código de alocação de memória tentará localizar páginas livres contíguas do ponto de vista do cache. Por exemplo, se a página 16 da memória física for atribuída à página 0 da memória virtual de um processo e o cache puder conter 4 páginas, o código de page coloring não atribuirá a página 20 da memória física a página 1 da memória virtual de um processo. Em vez disso, atribui a página 21 da memória física. O código de page coloring tenta evitar assimilar a página 20, porque ela é mapeada sobre a mesma memória cache da página 16 e resultaria em um armazenamento não otimizado. Este código adiciona uma quantidade significativa de complexidade ao subsistema de alocação de memória de VM, como você pode imaginar, mas o resultado vale o esforço. Page coloring torna a memória de VM tão determinante quanto a memória física em relação ao desempenho do cache. + + + + Conclusão + + A memória virtual em sistemas operacionais modernos deve abordar vários problemas diferentes de maneira eficiente e para muitos padrões de uso diferentes. A abordagem modular e algorítmica que o BSD historicamente teve nos permite estudar e entender a implementação atual, bem como substituir de forma relativamente limpa grandes seções do código. Houve uma série de melhorias no sistema de VM do FreeBSD nos últimos anos e o trabalho está em andamento. + + + + Sessão bônus de QA por Allen Briggs <email>briggs@ninthwonder.com</email> + + + + + O que é o algoritmo de intercalação ao qual você se refere em sua listagem dos males dos arranjos de swap do FreeBSD 3.X? + + + + 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 quatro áreas de troca 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 + + O FreeBSD 3.X usa uma abordagem de lista sequencial de regiões livres 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 (kern/subr_rlist.c). 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 livres e C e D mostrados como todos alocados. 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. + + 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. + + 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. + + 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. + + + + + + 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 systat -vm? As estatísticas do systat rolam as páginas ativa e inativas juntas para a contagem de filas ativas? + + Eu não entendo o seguinte: + +
+ É 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 systat -vm. +
+ + + + Sim, isto é confuso. A relação é meta versus realidade. 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. + + 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 -> fila inativa) quando o sistema não está sendo estressado, mesmo que não estejam sendo usados. + + + + + + No exemplo ls1 / vmstat 1, 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? + + + + 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 faz pré-mapeamento de páginas que existem em seu cache. + + + + + + Em sua seção sobre otimizações de tabela de páginas, você pode dar um pouco mais de detalhes sobre pv_entry e vm_page (ou vm_page deveria ser vm_pmap- 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? + + Como o Linux faz no caso onde o FreeBSD quebra (compartilhando um grande mapeamento de arquivos em muitos processos)? + + + + Uma vm_page representa uma tupla (objeto,índice#). Um pv_entry 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 vm_page e três estruturas pv_entry. + + As estruturas pv_entry representam apenas as páginas mapeadas pela MMU (uma pv_entry representa uma pte). Isso significa que quando precisamos remover todas as referências de hardware para uma vm_page (para reutilizar a página para outra coisa, paginar, limpar, inativar e assim por diante), podemos simplesmente escanear a lista encadeada de pv_entry associada a essa vm_page para remover ou modificar os pte's de suas tabelas de páginas. + + No Linux, não existe essa lista vinculada. Para remover todos os mapeamentos de tabelas de páginas de hardware para um vm_page, o linux deve indexar em todos os objetos de VM que possam 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. + + O FreeBSD adicionou complexidade (o esquema pv_entry) para aumentar o desempenho (para limitar os acessos da tabela de páginas a somente aqueles pte's que precisam ser modificados). + + Mas o FreeBSD tem um problema de escalonamento que o Linux não possui, pois há um número limitado de estruturas pv_entry e isso causa problemas quando você tem um compartilhamento massivo de dados. Nesse caso, você pode ficar sem estruturas pv_entry, mesmo que haja bastante memória livre disponível. Isto pode ser corrigido com bastante facilidade aumentando o número de estruturas pv_entry na configuração do kernel, mas realmente precisamos encontrar uma maneira melhor de fazê-lo. + + Em relação à sobrecarga de memória de uma tabela de páginas verso do esquema pv_entry: o Linux usa tabelas permanentes que não são descartadas, mas não precisa de um pv_entry para cada pte potencialmente mapeado. O FreeBSD usa tabelas de páginas throw away, mas adiciona em uma estrutura pv_entry 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. + + + + + + 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. + + + + 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 mesmo 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! + + Agora estou simplificando muito as coisas. O que acabei de descrever é o que é chamado de cache de memória de hardware diretamente mapeado. 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. + + 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. + + É extremamente importante… extremamente 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 centenas 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) é lenta, quando comparada à velocidade de um núcleo de processador moderno. + + Ok, agora em page coloring: Todos os caches de memória modernos são conhecidos como caches físicos. 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. + + Mas no mundo UNIX 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 físicas 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 física. + + 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). + + É isso que o disfarce de página faz. Em vez de atribuir páginas físicas aleatórias 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 razoavelmente contíguas 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 que eu digo razoavelmente contíguo ao invés de simplesmente contíguo. 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 não 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. + + + + +
Property changes on: head/pt_BR.ISO8859-1/articles/vm-design/article.xml ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/xml; charset=UTF-8 \ No newline at end of property Index: head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po =================================================================== --- head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po (nonexistent) +++ head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po (revision 52252) @@ -0,0 +1,1846 @@ +# $FreeBSD$ +# André Franciosi , 2018. #zanata +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Silvio Ap Silva , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-13 02:27+0000\n" +"PO-Revision-Date: 2018-09-12 11:08+0000\n" +"Last-Translator: André Franciosi \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018\n" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Silvio Ap Silva, contato@kanazuchi.com, 2018\n" +"André Franciosi, andre@franciosi.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:6 +msgid "Design elements of the FreeBSD VM system" +msgstr "Elementos de design do sistema de VM do FreeBSD" + +#. (itstool) path: affiliation/address +#: article.translate.xml:11 +#, no-wrap +msgid "" +"\n" +"\t dillon@apollo.backplane.com\n" +"\t " +msgstr "" +"\n" +"\t dillon@apollo.backplane.com\n" +"\t " + +#. (itstool) path: authorgroup/author +#: article.translate.xml:10 +msgid "" +"MatthewDillon <_:address-1/> " +msgstr "" +"MatthewDillon <_:address-1/> " + +#. (itstool) path: legalnotice/para +#: article.translate.xml:18 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:20 +msgid "Linux is a registered trademark of Linus Torvalds." +msgstr "Linux is a registered trademark of Linus Torvalds." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:22 +msgid "" +"Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows " +"NT are either registered trademarks or trademarks of Microsoft Corporation " +"in the United States and/or other countries." +msgstr "" +"Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows " +"NT are either registered trademarks or trademarks of Microsoft Corporation " +"in the United States and/or other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:26 +msgid "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." +msgstr "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:30 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:38 article.translate.xml:40 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/vm-design/article.xml 43184 " +"2013-11-13 07:52:45Z hrs $" +msgstr "" +"$FreeBSD: head/en_US.ISO8859-1/articles/vm-design/article.xml 43184 " +"2013-11-13 07:52:45Z hrs $" + +#. (itstool) path: abstract/para +#: article.translate.xml:43 +msgid "" +"The title is really just a fancy way of saying that I am going to attempt to " +"describe the whole VM enchilada, hopefully in a way that everyone can " +"follow. For the last year I have concentrated on a number of major kernel " +"subsystems within FreeBSD, with the VM and Swap subsystems being the most " +"interesting and NFS being a necessary chore. I rewrote only " +"small portions of the code. In the VM arena the only major rewrite I have " +"done is to the swap subsystem. Most of my work was cleanup and maintenance, " +"with only moderate code rewriting and no major algorithmic adjustments " +"within the VM subsystem. The bulk of the VM subsystem's theoretical base " +"remains unchanged and a lot of the credit for the modernization effort in " +"the last few years belongs to John Dyson and David Greenman. Not being a " +"historian like Kirk I will not attempt to tag all the various features with " +"peoples names, since I will invariably get it wrong." +msgstr "" +"O título é realmente apenas uma maneira extravagante de dizer que vou tentar " +"descrever todo o grupo de itens de uma VM, espero que de uma forma que todos " +"possam acompanhar. Pelo ultimo ano eu me concentrei em vários dos principais " +"subsistemas do kernel dentro do FreeBSD, com os subsistemas VM e Swap sendo " +"os mais interessantes e o NFS sendo uma tarefa necessária. Eu " +"reescrevi apenas pequenas partes do código. Na área de VM, a única grande " +"reescrita que fiz foi para o subsistema de troca. A maior parte do meu " +"trabalho foi de limpeza e manutenção, com apenas uma moderada reescrita de " +"código e sem grandes ajustes nos algorítimos do subsistema VM. A maior parte " +"da base teórica do subsistema VM permanece inalterada e muito do crédito " +"pelo esforço de modernização nos últimos anos pertence a John Dyson e David " +"Greenman. Não sendo um historiador como Kirk, eu não tentarei marcar todos " +"os vários recursos com nomes de pessoas, já que invariavelmente vou errar." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:60 +msgid "" +"This article was originally published in the January 2000 issue of DaemonNews. This version of " +"the article may include updates from Matt and other authors to reflect " +"changes in FreeBSD's VM implementation." +msgstr "" +"Este artigo foi publicado originalmente na edição de janeiro de 2000 do " +"DaemonNews. Esta " +"versão do artigo pode incluir atualizações feitas por Matt e outros autores " +"para refletir as mudanças na implementação da VM do FreeBSD." + +#. (itstool) path: sect1/title +#: article.translate.xml:68 +msgid "Introduction" +msgstr "Introdução" + +#. (itstool) path: sect1/para +#: article.translate.xml:70 +msgid "" +"Before moving along to the actual design let's spend a little time on the " +"necessity of maintaining and modernizing any long-living codebase. In the " +"programming world, algorithms tend to be more important than code and it is " +"precisely due to BSD's academic roots that a great deal of attention was " +"paid to algorithm design from the beginning. More attention paid to the " +"design generally leads to a clean and flexible codebase that can be fairly " +"easily modified, extended, or replaced over time. While BSD is considered an " +"old operating system by some people, those of us who work on " +"it tend to view it more as a mature codebase which has " +"various components modified, extended, or replaced with modern code. It has " +"evolved, and FreeBSD is at the bleeding edge no matter how old some of the " +"code might be. This is an important distinction to make and one that is " +"unfortunately lost to many people. The biggest error a programmer can make " +"is to not learn from history, and this is precisely the error that many " +"other modern operating systems have made. Windows NT is the best example of this, and the consequences " +"have been dire. Linux also makes this mistake to some degree—enough that we " +"BSD folk can make small jokes about it every once in a while, anyway. " +"Linux's problem is simply one of a lack of experience and history to compare " +"ideas against, a problem that is easily and rapidly being addressed by the " +"Linux community in the same way it has been addressed in the BSD community—" +"by continuous code development. The Windows NT folk, on the other hand, repeatedly make the same " +"mistakes solved by UNIX decades " +"ago and then spend years fixing them. Over and over again. They have a " +"severe case of not designed here and we are always " +"right because our marketing department says so. I have little " +"tolerance for anyone who cannot learn from history." +msgstr "" +"Antes de avançarmos para o design atual, vamos dedicar um pouco de tempo a " +"necessidade de manter e modernizar qualquer base de código duradoura. No " +"mundo da programação, os algoritmos tendem a ser mais importantes do que o " +"código, e é precisamente devido as raízes acadêmicas do BSD que uma grande " +"atenção foi dada ao design do algoritmo desde o início. Mais atenção ao " +"design geralmente leva a uma base de código limpa e flexível que pode ser " +"facilmente modificada, estendida ou substituída ao longo do tempo. Embora o " +"BSD seja considerado um sistema operacional antigo por " +"algumas pessoas, aqueles de nós que trabalham nele tendem a vê-lo mais como " +"uma base de código madura que possui vários componentes " +"modificados, estendidos, ou substituído por código moderno. Ele evoluiu e o " +"FreeBSD está no topo, não importa quantos anos tenha o código. Esta é uma " +"distinção importante a ser feita e infelizmente perdida para muitas pessoas. " +"O maior erro que um programador pode cometer é não aprender com a história, " +"e esse é precisamente o erro que muitos outros sistemas operacionais " +"modernos cometeram. Windows NT é " +"o melhor exemplo disso, e as conseqüências foram terríveis. O Linux também " +"cometeu esse erro até certo ponto - o suficiente para que nós, do BSD, " +"possamos fazer pequenas piadas sobre isso de vez em quando, entretanto. O " +"problema do Linux é simplesmente a falta de experiência e histórico para " +"comparar idéias, um problema que está sendo resolvido de forma fácil e " +"rápida pela comunidade Linux, da mesma forma como foi abordado na comunidade " +"BSD - pelo desenvolvimento contínuo de código. Por outro lado, o povo do " +"Windows NT, repetidamente comete " +"os mesmos erros resolvidos no UNIX décadas atrás e depois gasta anos corrigindo-os. De novo e de " +"novo. Eles têm um caso grave de não foi projetado aqui e " +"estamos sempre certos porque nosso departamento de marketing diz que " +"sim. Tenho pouca tolerância para quem não pode aprender com a " +"história." + +#. (itstool) path: sect1/para +#: article.translate.xml:99 +msgid "" +"Much of the apparent complexity of the FreeBSD design, especially in the VM/" +"Swap subsystem, is a direct result of having to solve serious performance " +"issues that occur under various conditions. These issues are not due to bad " +"algorithmic design but instead rise from environmental factors. In any " +"direct comparison between platforms, these issues become most apparent when " +"system resources begin to get stressed. As I describe FreeBSD's VM/Swap " +"subsystem the reader should always keep two points in mind:" +msgstr "" +"Grande parte da complexidade aparente do design do FreeBSD, especialmente no " +"subsistema VM/Swap, é um resultado direto de ter que resolver sérios " +"problemas de desempenho que ocorrem sob várias condições. Estes problemas " +"não se devem ao mau design de algorítimo, mas sim a fatores ambientais. Em " +"qualquer comparação direta entre plataformas, estes problemas tornam-se mais " +"aparentes quando os recursos do sistema começam a ficar estressados. Como " +"descrevo o subsistema VM/Swap do FreeBSD, o leitor deve sempre manter dois " +"pontos em mente:" + +#. (itstool) path: listitem/para +#: article.translate.xml:110 +msgid "" +"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 in order to make " +"the critical path perform better." +msgstr "" +"O aspecto mais importante do design de desempenho é o que é conhecido como " +"Otimizando o Caminho Crítico . Muitas vezes, as otimizações " +"de desempenho inflam um pouco o código, para que o caminho crítico tenha um " +"melhor desempenho." + +#. (itstool) path: listitem/para +#: article.translate.xml:117 +msgid "" +"A solid, generalized design outperforms a heavily-optimized design over the " +"long run. While a generalized design may end up being slower than an heavily-" +"optimized design when they are first implemented, the generalized design " +"tends to be easier to adapt to changing conditions and the heavily-optimized " +"design winds up having to be thrown away." +msgstr "" +"Um design sólido e generalizado supera um projeto altamente otimizado a " +"longo prazo. Enquanto um design generalizado pode acabar sendo mais lento do " +"que um projeto altamente otimizado quando eles são implementados pela " +"primeira vez, o design generalizado tende a ser mais fácil de se adaptar as " +"mudanças de condições e o projeto altamente otimizado acaba tendo que ser " +"descartado." + +#. (itstool) path: sect1/para +#: article.translate.xml:126 +msgid "" +"Any codebase that will survive and be maintainable for years must therefore " +"be designed properly from the beginning even if it costs some performance. " +"Twenty years ago people were still arguing that programming in assembly was " +"better than programming in a high-level language because it produced code " +"that was ten times as fast. Today, the fallibility of that argument is " +"obvious  — as are the parallels to algorithmic design and code " +"generalization." +msgstr "" +"Qualquer base de código que sobreviva e seja sustentável por anos deve, " +"portanto, ser projetada adequadamente desde o início, mesmo que isso custe " +"algum desempenho. Vinte anos atrás, as pessoas ainda argumentavam que " +"programar em assembly era melhor do que programar em uma linguagem de alto " +"nível porque produzia um código que era dez vezes mais rápido. Hoje, a queda " +"desse argumento é óbvia - assim como os paralelos com o design de algorítimo " +"e a generalização de código." + +#. (itstool) path: sect1/title +#: article.translate.xml:136 +msgid "VM Objects" +msgstr "Objetos de VM" + +#. (itstool) path: sect1/para +#: article.translate.xml:138 +msgid "" +"The best way to begin describing the FreeBSD VM system is to look at it from " +"the perspective of a user-level process. Each user process sees a single, " +"private, contiguous VM address space containing several types of memory " +"objects. These objects have various characteristics. Program code and " +"program data are effectively a single memory-mapped file (the binary file " +"being run), but program code is read-only while program data is copy-on-" +"write. Program BSS is just memory allocated and filled with zeros on demand, " +"called demand zero page fill. Arbitrary files can be memory-mapped into the " +"address space as well, which is how the shared library mechanism works. Such " +"mappings can require modifications to remain private to the process making " +"them. The fork system call adds an entirely new dimension to the VM " +"management problem on top of the complexity already given." +msgstr "" +"A melhor maneira de começar a descrever o sistema de VM do FreeBSD é examiná-" +"lo da perspectiva de um processo em nível de usuário. Cada processo do " +"usuário vê um espaço de endereço de VM único, privado e contíguo, contendo " +"vários tipos de objetos de memória. Esses objetos possuem várias " +"características. O código do programa e os dados do programa são " +"efetivamente um único arquivo mapeado na memória (o arquivo binário sendo " +"executado), mas o código do programa é read-only enquanto os dados do " +"programa são copy-on-write. O programa BSS é apenas memória alocada e " +"preenchida com zeros sob demanda, chamado de demanda de preenchimento de " +"página com zero. Arquivos arbitrários também podem ser mapeados na memória " +"dentro do espaço de endereçamento como bem entender, que é como o mecanismo " +"de biblioteca compartilhada funciona. Esses mapeamentos podem exigir " +"modificações para permanecerem privados para o processo que os produz. A " +"chamada do sistema de fork adiciona uma dimensão totalmente nova ao problema " +"de gerenciamento de VMs além da complexidade já fornecida." + +#. (itstool) path: sect1/para +#: article.translate.xml:152 +msgid "" +"A program binary data page (which is a basic copy-on-write page) illustrates " +"the complexity. A program binary contains a preinitialized data section " +"which is initially mapped directly from the program file. When a program is " +"loaded into a process's VM space, this area is initially memory-mapped and " +"backed by the program binary itself, allowing the VM system to free/reuse " +"the page and later load it back in from the binary. The moment a process " +"modifies this data, however, the VM system must make a private copy of the " +"page for that process. Since the private copy has been modified, the VM " +"system may no longer free it, because there is no longer any way to restore " +"it later on." +msgstr "" +"Uma página de dados binários do programa (que é uma página básica de copy-on-" +"write) ilustra a complexidade. Um programa binário contém uma seção de dados " +"pré-inicializada que é inicialmente mapeada diretamente a partir do arquivo " +"de programa. Quando um programa é carregado no espaço de VM de um processo, " +"esta área é inicialmente mapeada na memória e suportada pelo próprio binário " +"do programa, permitindo que o sistema de VM liberte/reutilize a página e " +"depois carregue-a de volta a partir do binário. No entanto, no momento em " +"que um processo modifica esses dados, o sistema de VM deve fazer uma cópia " +"privada da página para esse processo. A partir do momento que a cópia " +"privada tenha sido modificada, o sistema de VM pode não mais liberá-la, " +"porque não há mais como restaurá-la depois." + +#. (itstool) path: sect1/para +#: article.translate.xml:163 +msgid "" +"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 effect the other." +msgstr "" +"Você notará imediatamente que o que originalmente era um mapeamento de " +"arquivo simples se tornou muito mais complexo. Os dados podem ser " +"modificados página a página, enquanto o mapeamento de arquivos abrange " +"muitas páginas de uma só vez. A complexidade aumenta ainda mais quando " +"existe um fork do processo. Quando um processo se duplica, o resultado são " +"dois processos - cada um com seus próprios espaços de endereçamento " +"privados, incluindo quaisquer modificações feitas pelo processo original " +"antes de chamar um fork(). Seria bobagem o sistema de " +"VM fizesse uma cópia completa dos dados no momento do fork() porque é bem possível que pelo menos um dos dois processos precise " +"apenas ler essa página a partir de então, permitindo que a página original " +"continue a ser usada. O que era uma página privada é feito um copy-on-write " +"novamente, já que cada processo (pai e filho) espera que suas próprias " +"modificações pós-fork permaneçam privadas para si mesmas e não afetem a " +"outra." + +#. (itstool) path: sect1/para +#: article.translate.xml:178 +msgid "" +"FreeBSD manages all of this with a layered VM Object model. The original " +"binary program file winds up being the lowest VM Object layer. A copy-on-" +"write layer is pushed on top of that to hold those pages which had to be " +"copied from the original file. If the program modifies a data page belonging " +"to the original file the VM system takes a fault and makes a copy of the " +"page in the higher layer. When a process forks, additional VM Object layers " +"are pushed on. This might make a little more sense with a fairly basic " +"example. A fork() is a common operation for any *BSD " +"system, so this example will consider a program that starts up, and forks. " +"When the process starts, the VM system creates an object layer, let's call " +"this A:" +msgstr "" +"O FreeBSD gerencia tudo isso com um modelo de objetos de VM em camadas. O " +"arquivo de programa binário original acaba sendo a camada de objeto de VM " +"mais baixa. Uma camada copy-on-write é colocada acima dela para conter as " +"páginas que tiveram que ser copiadas do arquivo original. Se o programa " +"modificar uma página de dados pertencente ao arquivo original, o sistema de " +"VM assumirá que existe uma falha e fará uma cópia da página na camada " +"superior. Quando existe um fork do processo, as camadas adicionais de " +"objetos de VM são ativadas. Isso pode fazer um pouco mais de sentido com um " +"exemplo bastante básico. Um fork() é uma operação comum " +"para qualquer sistema *BSD, então este exemplo irá considerar um programa " +"que inicia e é feito um fork. Quando o processo é iniciado, o sistema de VM " +"cria uma camada de objeto, vamos chamar isso de A:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:192 +msgctxt "_" +msgid "external ref='fig1' md5='__failed__'" +msgstr "external ref='fig1' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:196 +#, no-wrap +msgid "" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/mediaobject +#: article.translate.xml:190 +msgid "" +" <_:" +"literallayout-1/> A picture " +msgstr "" +" <_:" +"literallayout-1/> A picture " + +#. (itstool) path: sect1/para +#: article.translate.xml:206 +msgid "" +"A represents the file—pages may be paged in and out of the file's physical " +"media as necessary. Paging in from the disk is reasonable for a program, but " +"we really do not want to page back out and overwrite the executable. The VM " +"system therefore creates a second layer, B, that will be physically backed " +"by swap space:" +msgstr "" +"A representa o arquivo - as páginas podem ser paginadas dentro e fora da " +"mídia física do arquivo, conforme necessário. Paginar a partir do disco é " +"razoável para um programa, mas nós realmente não queremos voltar atrás e " +"sobrescrever o executável. O sistema de VM, portanto, cria uma segunda " +"camada, B, que será fisicamente suportada pelo espaço de troca:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:214 +msgctxt "_" +msgid "external ref='fig2' md5='__failed__'" +msgstr "external ref='fig2' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:218 +#, no-wrap +msgid "" +"+---------------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+---------------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:226 +msgid "" +"On the first write to a page after this, a new page is created in B, and its " +"contents are initialized from A. All pages in B can be paged in or out to a " +"swap device. When the program forks, the VM system creates two new object " +"layers—C1 for the parent, and C2 for the child—that rest on top of B:" +msgstr "" +"Na primeira escrita em uma página depois disso, uma nova página é criada em " +"B e seu conteúdo é inicializado a partir de A. Todas as páginas em B podem " +"ser paginadas para dentro ou para fora por um dispositivo de troca. Quando é " +"feito o fork do programa, o sistema de VM cria duas novas camadas de objetos " +"- C1 para o processo pai e C2 para o filho - que ficam no topo de B:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:234 +msgctxt "_" +msgid "external ref='fig3' md5='__failed__'" +msgstr "external ref='fig3' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:238 +#, no-wrap +msgid "" +"+-------+-------+\n" +"| C1 | C2 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+-------+-------+\n" +"| C1 | C2 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:248 +msgid "" +"In this case, let's say a page in B is modified by the original parent " +"process. The process will take a copy-on-write fault and duplicate the page " +"in C1, leaving the original page in B untouched. Now, let's say the same " +"page in B is modified by the child process. The process will take a copy-on-" +"write fault and duplicate the page in C2. The original page in B is now " +"completely hidden since both C1 and C2 have a copy and B could theoretically " +"be destroyed if it does not represent a real file; however, " +"this sort of optimization is not trivial to make because it is so fine-" +"grained. FreeBSD does not make this optimization. Now, suppose (as is often " +"the case) that the child process does an exec(). Its " +"current address space is usually replaced by a new address space " +"representing a new file. In this case, the C2 layer is destroyed:" +msgstr "" +"Neste caso, digamos que uma página em B seja modificada pelo processo pai " +"original. O processo terá uma falha de copy-on-write e duplicará a página em " +"C1, deixando a página original em B intocada. Agora, digamos que a mesma " +"página em B seja modificada pelo processo filho. O processo assumirá uma " +"falha de copy-on-write e duplicará a página em C2. A página original em B " +"agora está completamente oculta, já que C1 e C2 têm uma cópia e B poderia, " +"teoricamente, ser destruído se não representasse um arquivo real; no entanto, esse tipo de otimização não é trivial de se fazer, " +"porque é muito refinado. O FreeBSD não faz essa otimização. Agora, suponha " +"(como é frequentemente o caso) que o processo filho execute um " +"exec(). Seu espaço de endereço atual é geralmente " +"substituído por um novo espaço de endereço representando um novo arquivo. " +"Nesse caso, a camada C2 é destruída:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:264 +msgctxt "_" +msgid "external ref='fig4' md5='__failed__'" +msgstr "external ref='fig4' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:268 +#, no-wrap +msgid "" +"+-------+\n" +"| C1 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+-------+\n" +"| C1 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:278 +msgid "" +"In this case, the number of children of B drops to one, and all accesses to " +"B now go through C1. This means that B and C1 can be collapsed together. Any " +"pages in B that also exist in C1 are deleted from B during the collapse. " +"Thus, even though the optimization in the previous step could not be made, " +"we can recover the dead pages when either of the processes exit or " +"exec()." +msgstr "" +"Neste caso, o número de filhos de B cai para um, e todos os acessos para B " +"passam agora por C1. Isso significa que B e C1 podem ser unidas. Todas as " +"páginas em B que também existem em C1 são excluídas de B durante a união. " +"Assim, mesmo que a otimização na etapa anterior não possa ser feita, podemos " +"recuperar as páginas mortas quando um dos processos finalizar ou executar um " +"exec()." + +#. (itstool) path: sect1/para +#: article.translate.xml:285 +msgid "" +"This model creates a number of potential problems. The first is that you can " +"wind up with a relatively deep stack of layered VM Objects which can cost " +"scanning time and memory when you take a fault. Deep layering can occur when " +"processes fork and then fork again (either parent or child). The second " +"problem is that you can wind up with dead, inaccessible pages deep in the " +"stack of VM Objects. In our last example if both the parent and child " +"processes modify the same page, they both get their own private copies of " +"the page and the original page in B is no longer accessible by anyone. That " +"page in B can be freed." +msgstr "" +"Este modelo cria vários problemas potenciais. O primeiro é que você pode " +"acabar com uma pilha relativamente profunda de objetos de VM em camadas, que " +"pode custar tempo de varredura e memória quando ocorrer uma falha. Camadas " +"profundas podem ocorrer quando houver forks dos processos e, em seguida, " +"houver um fork novamente (do processo pai ou filho). O segundo problema é " +"que você pode acabar com páginas profundas inacessíveis e mortas no meio da " +"pilha de objetos de VM. Em nosso último exemplo, se os processos pai e filho " +"modificarem a mesma página, ambos receberão suas próprias cópias privadas da " +"página e a página original em B não poderá mais ser acessada por ninguém. " +"Essa página em B pode ser liberada." + +#. (itstool) path: sect1/para +#: article.translate.xml:295 +msgid "" +"FreeBSD solves the deep layering problem with a special optimization called " +"the All Shadowed Case. This case occurs if either C1 or C2 " +"take sufficient COW faults to completely shadow all pages in B. Lets say " +"that C1 achieves this. C1 can now bypass B entirely, so rather then have C1-" +">B->A and C2->B->A we now have C1->A and C2->B->A. But " +"look what also happened—now B has only one reference (C2), so we can " +"collapse B and C2 together. The end result is that B is deleted entirely and " +"we have C1->A and C2->A. It is often the case that B will contain a " +"large number of pages and neither C1 nor C2 will be able to completely " +"overshadow it. If we fork again and create a set of D layers, however, it is " +"much more likely that one of the D layers will eventually be able to " +"completely overshadow the much smaller dataset represented by C1 or C2. The " +"same optimization will work at any point in the graph and the grand result " +"of this is that even on a heavily forked machine VM Object stacks tend to " +"not get much deeper then 4. This is true of both the parent and the children " +"and true whether the parent is doing the forking or whether the children " +"cascade forks." +msgstr "" +"O FreeBSD resolve o problema de camadas profundas com uma otimização " +"especial chamada All Shadowed Case. Este caso ocorre se C1 ou " +"C2 tiverem falhas de COW suficientes para fazer uma copia de sombra completa " +"de todas as páginas em B. Digamos que C1 consiga isso. C1 agora pode ignorar " +"B completamente, então, em vez de temos C1->B->A e C2->B->A " +"temos agora C1->A e C2->B->A. Mas veja o que também aconteceu - " +"agora B tem apenas uma referência (C2), então podemos unir B e C2. O " +"resultado final é que B é deletado inteiramente e temos C1->A e C2->A. " +"É comum que B contenha um grande número de páginas e nem C1 nem C2 possam " +"ofuscar completamente. Se nós forçarmos novamente e criarmos um conjunto de " +"camadas D, no entanto, é muito mais provável que uma das camadas D " +"eventualmente seja capaz de ofuscar completamente o conjunto de dados muito " +"menor representado por C1 ou C2. A mesma otimização funcionará em qualquer " +"ponto do gráfico e o grande resultado disso é que, mesmo em uma máquina " +"diversos forks, pilhas de objetos da VM tendem a não ficar muito mais " +"profundas do que 4. Isso é verdade tanto para o processo pai quanto para os " +"filhos e verdadeiro quer seja o processo pai fazendo o fork ou os processos " +"filhos fazendo forks em cascata." + +#. (itstool) path: sect1/para +#: article.translate.xml:313 +msgid "" +"The dead page problem still exists in the case where C1 or C2 do not " +"completely overshadow B. Due to our other optimizations this case does not " +"represent much of a problem and we simply allow the pages to be dead. If the " +"system runs low on memory it will swap them out, eating a little swap, but " +"that is it." +msgstr "" +"O problema da página morta ainda existe no caso em que C1 ou C2 não " +"ofuscaram completamente as páginas de B. Devido as nossas outras " +"otimizações, este caso não representa um grande problema e simplesmente " +"permitimos que as páginas fiquem inativas. Se o sistema ficar com pouca " +"memória, ele irá trocá-las, comendo uma pequena parte da swap, mas é isso." + +#. (itstool) path: sect1/para +#: article.translate.xml:319 +msgid "" +"The advantage to the VM Object model is that fork() is " +"extremely fast, since no real data copying need take place. The disadvantage " +"is that you can build a relatively complex VM Object layering that slows " +"page fault handling down a little, and you spend memory managing the VM " +"Object structures. The optimizations FreeBSD makes proves to reduce the " +"problems enough that they can be ignored, leaving no real disadvantage." +msgstr "" +"A vantagem do modelo de objetos de VM é que o fork() é " +"extremamente rápido, já que não é necessária nenhuma cópia de dados real. A " +"desvantagem é que você pode criar uma camada de Objetos de VM relativamente " +"complexa que reduz um pouco o tratamento de falhas de página e gasta memória " +"gerenciando as estruturas de Objetos de VM. As otimizações que o FreeBSD faz " +"prova reduzir os problemas o suficiente para que as falhas possam ser " +"ignoradas, não deixando nenhuma desvantagem real." + +#. (itstool) path: sect1/title +#: article.translate.xml:329 +msgid "SWAP Layers" +msgstr "Camadas de SWAP" + +#. (itstool) path: sect1/para +#: article.translate.xml:331 +msgid "" +"Private data pages are initially either copy-on-write or zero-fill pages. " +"When a change, and therefore a copy, is made, the original backing object " +"(usually a file) can no longer be used to save a copy of the page when the " +"VM system needs to reuse it for other purposes. This is where SWAP comes in. " +"SWAP is allocated to create backing store for memory that does not otherwise " +"have it. FreeBSD allocates the swap management structure for a VM Object " +"only when it is actually needed. However, the swap management structure has " +"had problems historically:" +msgstr "" +"As páginas de dados privadas são inicialmente páginas copy-on-write ou zero-" +"fill. Quando uma alteração e, portanto, uma cópia, é feita, o objeto de " +"apoio original (geralmente um arquivo) não pode mais ser usado para salvar " +"uma cópia da página quando o sistema da VM precisar reutilizá-lo para outras " +"finalidades. É aí que o SWAP entra. O SWAP é alocado para criar um suporte " +"de armazenamento para a memória que não o possui. O FreeBSD aloca a " +"estrutura de gerenciamento de troca para um objeto de VM somente quando for " +"realmente necessário. No entanto, historicamente, a estrutura de " +"gerenciamento de troca teve problemas:" + +#. (itstool) path: listitem/para +#: article.translate.xml:343 +msgid "" +"Under FreeBSD 3.X the swap management structure preallocates an array that " +"encompasses the entire object requiring swap backing store—even if only a " +"few pages of that object are swap-backed. This creates a kernel memory " +"fragmentation problem when large objects are mapped, or processes with large " +"runsizes (RSS) fork." +msgstr "" +"Sob o FreeBSD 3.X, a estrutura de gerenciamento de swap pré-aloca uma matriz " +"que engloba todo o objeto que requer suporte para armazenamento da swap - " +"mesmo que apenas algumas páginas desse objeto sejam suportadas por swap. " +"Isto cria um problema de fragmentação de memória do kernel quando grandes " +"objetos são mapeados ou processos com fork de grandes runsizes (RSS)." + +#. (itstool) path: listitem/para +#: article.translate.xml:352 +msgid "" +"Also, in order 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." +msgstr "" +"Além disso, para manter o controle do espaço de swap, uma lista de " +"espaços vazios é mantida na memória do kernel, e isso tende a ficar " +"severamente fragmentado também. Como a lista de espaços vazios é uma lista linear, o desempenho de alocação e liberação de swap é " +"uma troca O(n)-per-page (Uma por página) não ideal." + +#. (itstool) path: listitem/para +#: article.translate.xml:360 +msgid "" +"It requires kernel memory allocations to take place during the swap freeing " +"process, and that creates low memory deadlock problems." +msgstr "" +"Requer que as alocações de memória do kernel ocorram durante o processo de " +"troca de swap, e isto cria problemas de deadlock de pouca memória." + +#. (itstool) path: listitem/para +#: article.translate.xml:366 +msgid "" +"The problem is further exacerbated by holes created due to the interleaving " +"algorithm." +msgstr "" +"O problema é ainda mais exacerbado por buracos criados devido ao algoritmo " +"de intercalação." + +#. (itstool) path: listitem/para +#: article.translate.xml:371 +msgid "" +"Also, the swap block map can become fragmented fairly easily resulting in " +"non-contiguous allocations." +msgstr "" +"Além disso, o mapa de blocos da swap pode se fragmentar com bastante " +"facilidade, resultando em alocações não contíguas." + +#. (itstool) path: listitem/para +#: article.translate.xml:376 +msgid "" +"Kernel memory must also be allocated on the fly for additional swap " +"management structures when a swapout occurs." +msgstr "" +"A memória do kernel também deve ser alocada dinamicamente para estruturas " +"adicionais de gerenciamento da swap quando ocorre uma troca." + +#. (itstool) path: sect1/para +#: article.translate.xml:381 +msgid "" +"It is evident from that list that there was plenty of room for improvement. " +"For FreeBSD 4.X, I completely rewrote the swap subsystem:" +msgstr "" +"É evidente a partir dessa lista que havia muito espaço para melhorias. Para " +"o FreeBSD 4.X, eu reescrevi completamente o subsistema de swap:" + +#. (itstool) path: listitem/para +#: article.translate.xml:387 +msgid "" +"Swap management structures are allocated through a hash table rather than a " +"linear array giving them a fixed allocation size and much finer granularity." +msgstr "" +"As estruturas de gerenciamento de swap são alocadas por meio de uma tabela " +"de hash, em vez de um array linear, fornecendo um tamanho de alocação fixo e " +"uma granularidade muito mais fina." + +#. (itstool) path: listitem/para +#: article.translate.xml:393 +msgid "" +"Rather then using a linearly linked list to keep track of swap space " +"reservations, it now uses a bitmap of swap blocks arranged in a radix tree " +"structure with free-space hinting in the radix node structures. This " +"effectively makes swap allocation and freeing an O(1) operation." +msgstr "" +"Em vez de usar uma lista vinculada linearmente para acompanhar as reservas " +"de espaço de troca, ele agora usa um bitmap de blocos de troca organizados " +"em uma estrutura de árvores raiz com dicas de espaço livre nas estruturas do " +"nó de origem. Isto efetivamente faz a alocação de swap e libera uma operação " +"O(1)." + +#. (itstool) path: listitem/para +#: article.translate.xml:401 +msgid "" +"The entire radix tree bitmap is also preallocated in order 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 in order to avoid potential " +"deadlocks." +msgstr "" +"Todo o bitmap da árvore raiz também é pré-alocado para evitar ter que alocar " +"a memória do kernel durante operações críticas de troca com memória baixa. " +"Afinal de contas, o sistema tende a trocar quando está com pouca memória, " +"por isso devemos evitar a alocação da memória do kernel nesses momentos para " +"evitar possíveis deadlocks." + +#. (itstool) path: listitem/para +#: article.translate.xml:410 +msgid "" +"To reduce fragmentation the radix tree is capable of allocating large " +"contiguous chunks at once, skipping over smaller fragmented chunks." +msgstr "" +"Para reduzir a fragmentação, a árvore raiz é capaz de alocar grandes blocos " +"contíguos de uma só vez, pulando pedaços menores e fragmentados." + +#. (itstool) path: sect1/para +#: article.translate.xml:416 +msgid "" +"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 " +"in order to further guarantee contiguous allocations or at least locality of " +"reference, but I ensured that such an addition could be made." +msgstr "" +"Eu não dei o último passo de ter um ponteiro de sugestão de alocação que percorria uma porção da swap conforme as alocações eram feitas a " +"fim de garantir alocações contíguas ou pelo menos a referência localmente, " +"mas assegurei que tal adição poderia ser feita." + +#. (itstool) path: sect1/title +#: article.translate.xml:424 +msgid "When to free a page" +msgstr "Quando libertar uma página" + +#. (itstool) path: sect1/para +#: article.translate.xml:426 +msgid "" +"Since the VM system uses all available memory for disk caching, there are " +"usually very few truly-free pages. The VM system depends on being able to " +"properly choose pages which are not in use to reuse for new allocations. " +"Selecting the optimal pages to free is possibly the single-most important " +"function any VM system can perform because if it makes a poor selection, the " +"VM system may be forced to unnecessarily retrieve pages from disk, seriously " +"degrading system performance." +msgstr "" +"Como o sistema de VM usa toda a memória disponível para o cache em disco, " +"geralmente há poucas páginas realmente livres. O sistema de VM depende de " +"poder escolher corretamente as páginas que não estão em uso para reutilizar " +"em novas alocações. Selecionar as páginas ideais para liberar é " +"possivelmente a função mais importante que qualquer sistema de VM pode " +"executar, porque se fizer uma seleção ruim, o sistema de VM poderá ser " +"desnecessariamente forçado a recuperar páginas do disco, prejudicando " +"seriamente o desempenho do sistema." + +#. (itstool) path: sect1/para +#: article.translate.xml:434 +msgid "" +"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 in order to be " +"sure that the right page is chosen. This is why FreeBSD tends to outperform " +"other systems when memory resources become stressed." +msgstr "" +"Quanta sobrecarga estamos dispostos a sofrer no caminho crítico para evitar " +"a liberação da página errada? Cada escolha errada que fazemos nos custará " +"centenas de milhares de ciclos da CPU e uma paralisação notável dos " +"processos afetados, por isto estamos dispostos a suportar uma quantidade " +"significativa de sobrecarga, a fim de ter certeza de que a página certa é " +"escolhida. É por isto que o FreeBSD tende a superar outros sistemas quando " +"os recursos de memória ficam estressados." + +#. (itstool) path: sect1/para +#: article.translate.xml:442 +msgid "" +"The free page determination algorithm is built upon a history of the use of " +"memory pages. To acquire this history, the system takes advantage of a page-" +"used bit feature that most hardware page tables have." +msgstr "" +"O algoritmo de determinação de página livre é construído sobre um histórico " +"do uso das páginas de memória. Para adquirir este histórico, o sistema tira " +"proveito de um recurso de um bit usado pela página que a maioria das tabelas " +"de página de hardware possui." + +#. (itstool) path: sect1/para +#: article.translate.xml:446 +msgid "" +"In any case, the page-used bit is cleared and at some later point the VM " +"system comes across the page again and sees that the page-used bit has been " +"set. This indicates that the page is still being actively used. If the bit " +"is still clear it is an indication that the page is not being actively used. " +"By testing this bit periodically, a use history (in the form of a counter) " +"for the physical page is developed. When the VM system later needs to free " +"up some pages, checking this history becomes the cornerstone of determining " +"the best candidate page to reuse." +msgstr "" +"Em qualquer caso, o bit usado na página é desmarcado e, em algum momento " +"posterior, o sistema de VM encontra a página novamente e vê que o bit usado " +"na página foi definido. Isso indica que a página ainda está sendo usada " +"ativamente. Se o bit ainda estiver desmarcado, é uma indicação de que a " +"página não está sendo usada ativamente. Ao testar este bit periodicamente, é " +"desenvolvido um histórico de uso (na forma de um contador) para a página " +"física. Quando, posteriormente, o sistema de VM precisar liberar algumas " +"páginas, a verificação desse histórico se tornará a base da determinação da " +"melhor página candidata a ser reutilizada." + +#. (itstool) path: sidebar/title +#: article.translate.xml:456 +msgid "What if the hardware has no page-used bit?" +msgstr "E se o hardware não tiver o bit usado na página?" + +#. (itstool) path: sidebar/para +#: article.translate.xml:458 +msgid "" +"For those platforms that do not have this feature, the system actually " +"emulates a page-used bit. It unmaps or protects a page, forcing a page fault " +"if the page is accessed again. When the page fault is taken, the system " +"simply marks the page as having been used and unprotects the page so that it " +"may be used. While taking such page faults just to determine if a page is " +"being used appears to be an expensive proposition, it is much less expensive " +"than reusing the page for some other purpose only to find that a process " +"needs it back and then have to go to disk." +msgstr "" +"Para as plataformas que não possuem esse recurso, o sistema realmente emula " +"um bit usado na página. Ele remove o mapeamento ou protege uma página, " +"forçando uma falha de página se a página for acessada novamente. Quando a " +"falha de página acontece, o sistema simplesmente marca a página como tendo " +"sido usada e desprotege a página para que ela possa ser usada. Embora a " +"tomada de tais falhas de página apenas para determinar se uma página está " +"sendo usada pareça ser uma proposta cara, é muito menos dispendioso do que " +"reutilizar a página para outra finalidade, apenas para descobrir que um " +"processo precisa dela e depois ir para o disco ." + +#. (itstool) path: sect1/para +#: article.translate.xml:469 +msgid "" +"FreeBSD makes use of several page queues to further refine the selection of " +"pages to reuse as well as to determine when dirty pages must be flushed to " +"their backing store. Since page tables are dynamic entities under FreeBSD, " +"it costs virtually nothing to unmap a page from the address space of any " +"processes using it. When a page candidate has been chosen based on the page-" +"use counter, this is precisely what is done. The system must make a " +"distinction between clean pages which can theoretically be freed up at any " +"time, and dirty pages which must first be written to their backing store " +"before being reusable. When a page candidate has been found it is moved to " +"the inactive queue if it is dirty, or the cache queue if it is clean. A " +"separate algorithm based on the dirty-to-clean page ratio determines when " +"dirty pages in the inactive queue must be flushed to disk. Once this is " +"accomplished, the flushed pages are moved from the inactive queue to the " +"cache queue. At this point, pages in the cache queue can still be " +"reactivated by a VM fault at relatively low cost. However, pages in the " +"cache queue are considered to be immediately freeable and " +"will be reused in an LRU (least-recently used) fashion when the system needs " +"to allocate new memory." +msgstr "" +"O FreeBSD faz uso de várias filas de páginas para refinar ainda mais a " +"seleção de páginas para reutilização, bem como para determinar quando " +"páginas inativas devem ser liberadas para o suporte ao armazenamento. Como " +"as tabelas de páginas são entidades dinâmicas sob o FreeBSD, não custa " +"virtualmente nada desmapear uma página do espaço de endereço de qualquer " +"processo que a utilize. Quando uma página cadidata ser escolhida com base no " +"contador de uso de página, isso é precisamente o que é feito. O sistema deve " +"fazer uma distinção entre páginas limpas que teoricamente podem ser " +"liberadas a qualquer momento, e páginas inativas que devem primeiro ser " +"escritas em seu repositório de armazenamento antes de serem reutilizáveis. " +"Quando uma página candidata for encontrada, ela será movida para a fila " +"inativa, se estiver inativas, ou para a fila de cache, se estiver limpa. Um " +"algoritmo separado baseado na proporção de páginas inativas para limpas " +"determina quando páginas inativas na fila inativa devem ser liberadas para o " +"disco. Depois que isso for feito, as páginas liberadas serão movidas da fila " +"inativa para a fila de cache. Neste ponto, as páginas na fila de cache ainda " +"podem ser reativadas por uma falha de VM a um custo relativamente baixo. No " +"entanto, as páginas na fila de cache são consideradas imediatamente " +"livres e serão reutilizadas em uma forma LRU (usada menos " +"recentemente) quando o sistema precisar alocar nova memória." + +#. (itstool) path: sect1/para +#: article.translate.xml:489 +msgid "" +"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 systat -vm command. As the VM system becomes more stressed, it makes a greater " +"effort to maintain the various page queues at the levels determined to be " +"the most effective." +msgstr "" +"É 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 move páginas " +"entre as várias filas de páginas gratuitamente quando o subsistema de " +"memória não está sendo enfatizado. É por isto que você verá alguns sistemas " +"com contagens de fila de cache muito baixas e contagens alta de fila ativa " +"ao executar um comando systat -vm. À medida que o sistema " +"de VM se torna mais estressado, ele faz um esforço maior para manter as " +"várias filas de páginas nos níveis determinados para serem mais eficazes." + +#. (itstool) path: sect1/para +#: article.translate.xml:499 +msgid "" +"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 in order " +"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." +msgstr "" +"Uma lenda urbana circulou durante anos que o Linux fez um trabalho melhor " +"evitando trocas do que o FreeBSD, mas isso de fato não é verdade. O que " +"estava realmente ocorrendo era que o FreeBSD estava proativamente numerando " +"páginas não usadas a fim de abrir espaço para mais cache de disco enquanto o " +"Linux mantinha páginas não utilizadas no núcleo e deixando menos memória " +"disponível para páginas de cache e processo. Eu não sei se isso ainda é " +"verdade hoje." + +#. (itstool) path: sect1/title +#: article.translate.xml:509 +msgid "Pre-Faulting and Zeroing Optimizations" +msgstr "Otimizações de Pré-Falhas ou para Zerar" + +#. (itstool) path: sect1/para +#: article.translate.xml:511 +msgid "" +"Taking a VM fault is not expensive if the underlying page is already in core " +"and can simply be mapped into the process, but it can become expensive if " +"you take a whole lot of them on a regular basis. A good example of this is " +"running a program such as ls1 or " +"ps1 over and over again. If the program binary is mapped into " +"memory but not mapped into the page table, then all the pages that will be " +"accessed by the program will have to be faulted in every time the program is " +"run. This is unnecessary when the pages in question are already in the VM " +"Cache, so FreeBSD will attempt to pre-populate a process's page tables with " +"those pages that are already in the VM Cache. One thing that FreeBSD does " +"not yet do is pre-copy-on-write certain pages on exec. For example, if you " +"run the ls1 program while running vmstat 1 " +"you will notice that it always takes a certain number of page faults, even " +"when you run it over and over again. These are zero-fill faults, not program " +"code faults (which were pre-faulted in already). Pre-copying pages on exec " +"or fork is an area that could use more study." +msgstr "" +"Pegar uma falha de VM não é caro se a página subjacente já estiver no núcleo " +"e puder simplesmente ser mapeada no processo, mas pode se tornar cara se " +"você pegar muitas delas regularmente. Um bom exemplo disso é executar um " +"programa como ls1 ou ps1 várias vezes. Se o " +"programa binário é mapeado na memória, mas não mapeado na tabela de páginas, " +"então todas as páginas que serão acessadas pelo programa irão estar com " +"falha toda vez que o programa for executado. Isso é desnecessário quando as " +"páginas em questão já estão no cache de VM, então o FreeBSD tentará " +"preencher previamente as tabelas de páginas de um processo com as páginas " +"que já estão no cache de VM. Uma coisa que o FreeBSD ainda não faz é pré-" +"copiar-durante-escrita certas páginas no exec. Por exemplo, se você executar " +"o programa ls1 ao executar o vmstat 1, notará " +"que sempre pega um determinado número de falhas de página, mesmo quando você " +"o executa várias vezes. Estas são falhas de preenchimento com zero, não " +"falhas de código de programa (que já foram pré-falhas). A pré-cópia de " +"páginas em exec ou fork é uma área que poderia se utilizar de mais estudos." + +#. (itstool) path: sect1/para +#: article.translate.xml:529 +msgid "" +"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 in order to avoid blowing " +"away the memory caches. This is an excellent example of adding complexity to " +"the VM system in order to optimize the critical path." +msgstr "" +"Uma grande porcentagem de falhas de página que ocorrem são falhas de " +"preenchimento com zero. Geralmente, você pode ver isso observando a saída de " +"vmstat -s. Estas falhas ocorrem quando um processo acessa " +"páginas em sua área BSS. Espera-se que a área BSS seja inicialmente zero, " +"mas o sistema de VM não se preocupa em alocar memória alguma até que o " +"processo realmente a acesse. Quando ocorre uma falha, o sistema de VM deve " +"alocar não apenas uma nova página, mas deve zerá-la também. Para otimizar a " +"operação de zeramento, o sistema de VM tem a capacidade de pré-zerar páginas " +"e marcá-las como tal, e solicitar páginas pré-zeradas quando ocorrem falhas " +"de preenchimento com zero. O pré-zeramento ocorre sempre que a CPU está " +"inativa, mas o número de páginas que o sistema pre-zeros é limitado, a fim " +"de evitar que os caches de memória sejam dissipados. Este é um excelente " +"exemplo de adição de complexidade ao sistema de VM para otimizar o caminho " +"crítico." + +#. (itstool) path: sect1/title +#: article.translate.xml:545 +msgid "Page Table Optimizations" +msgstr "Otimizações da Tabela de Páginas" + +#. (itstool) path: sect1/para +#: article.translate.xml:547 +msgid "" +"The page table optimizations make up the most contentious part of the " +"FreeBSD VM design and they have shown some strain with the advent of serious " +"use of mmap(). I think this is actually a feature of " +"most BSDs though I am not sure when it was first introduced. There are two " +"major optimizations. The first is that hardware page tables do not contain " +"persistent state but instead can be thrown away at any time with only a " +"minor amount of management overhead. The second is that every active page " +"table entry in the system has a governing pv_entry " +"structure which is tied into the vm_page structure. " +"FreeBSD can simply iterate through those mappings that are known to exist " +"while Linux must check all page tables that might " +"contain a specific mapping to see if it does, which can achieve O(n^2) " +"overhead in certain situations. It is because of this that FreeBSD tends to " +"make better choices on which pages to reuse or swap when memory is stressed, " +"giving it better performance under load. However, FreeBSD requires kernel " +"tuning to accommodate large-shared-address-space situations such as those " +"that can occur in a news system because it may run out of pv_entry structures." +msgstr "" +"As otimizações da tabela de páginas constituem a parte mais contenciosa do " +"design de VM do FreeBSD e mostraram alguma tensão com o advento do uso sério " +"de mmap(). Eu acho que isso é realmente uma " +"característica da maioria dos BSDs, embora eu não tenha certeza de quando " +"foi introduzido pela primeira vez. Existem duas otimizações principais. A " +"primeira é que as tabelas de páginas de hardware não contêm estado " +"persistente, mas podem ser descartadas a qualquer momento com apenas uma " +"pequena quantidade de sobrecarga de gerenciamento. A segunda é que cada " +"entrada ativa da tabela de páginas no sistema tem uma estrutura governante " +"pv_entry que é amarrada na estrutura vm_page. O FreeBSD pode simplesmente iterar através desses mapeamentos que " +"são conhecidos, enquanto o Linux deve verificar todas as tabelas de páginas " +"que possam conter um mapeamento específico para ver se " +"ele o faz, o que pode alcançar O(n^2) situações. É por isso que o FreeBSD " +"tende a fazer melhores escolhas em quais páginas reutilizar ou trocar quando " +"a memória é estressada, dando-lhe melhor desempenho em sobrecarga. No " +"entanto, o FreeBSD requer o ajuste do kernel para acomodar situações de " +"grandes espaços de endereços compartilhados, como aquelas que podem ocorrer " +"em um sistema de notícias, porque ele pode rodar sem estruturas " +"pv_entry." + +#. (itstool) path: sect1/para +#: article.translate.xml:567 +msgid "" +"Both Linux and FreeBSD need work in this area. FreeBSD is trying to maximize " +"the advantage of a potentially sparse active-mapping model (not all " +"processes need to map all pages of a shared library, for example), whereas " +"Linux is trying to simplify its algorithms. FreeBSD generally has the " +"performance advantage here at the cost of wasting a little extra memory, but " +"FreeBSD breaks down in the case where a large file is massively shared " +"across hundreds of processes. Linux, on the other hand, breaks down in the " +"case where many processes are sparsely-mapping the same shared library and " +"also runs non-optimally when trying to determine whether a page can be " +"reused or not." +msgstr "" +"Tanto o Linux quanto o FreeBSD precisam funcionar nesta área. O FreeBSD está " +"tentando maximizar a vantagem de um modelo de mapeamento ativo " +"potencialmente esparso (nem todos os processos precisam mapear todas as " +"páginas de uma biblioteca compartilhada, por exemplo), enquanto o Linux está " +"tentando simplificar seus algoritmos. O FreeBSD geralmente tem a vantagem de " +"desempenho aqui, ao custo de desperdiçar um pouco de memória extra, mas o " +"FreeBSD quebra no caso em que um arquivo grande é massivamente compartilhado " +"em centenas de processos. O Linux, por outro lado, se quebra no caso em que " +"muitos processos mapeiam esparsamente a mesma biblioteca compartilhada e " +"também são executados de maneira não ideal ao tentar determinar se uma " +"página pode ser reutilizada ou não." + +#. (itstool) path: sect1/title +#: article.translate.xml:580 +msgid "Page Coloring" +msgstr "Page Coloring" + +#. (itstool) path: sect1/para +#: article.translate.xml:582 +msgid "" +"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)." +msgstr "" +"Terminaremos com as otimizações de page coloring. Page coloring é uma " +"otimização de desempenho projetada para garantir que acessos a páginas " +"contíguas na memória virtual façam o melhor uso do cache do processador. Nos " +"tempos antigos (isto é, há mais de 10 anos), os caches de processador " +"tendiam a mapear a memória virtual em vez da memória física. Isso levou a um " +"grande número de problemas, incluindo a necessidade de limpar o cache em " +"cada troca de contexto em alguns casos e problemas com o alias de dados no " +"cache. Caches de processador modernos mapeiam a memória física com precisão " +"para resolver esses problemas. Isto significa que duas páginas lado a lado " +"em um espaço de endereço de processos podem não corresponder a duas páginas " +"lado a lado no cache. Na verdade, se você não for cuidadoso, as páginas lado " +"a lado na memória virtual podem acabar usando a mesma página no cache do " +"processador - conduzindo para que dados em cache sejam descartados " +"prematuramente e reduzindo o desempenho da CPU. Isto é verdade mesmo com " +"caches auto associativos de múltiplas vias (embora o efeito seja um pouco " +"mitigado)." + +#. (itstool) path: sect1/para +#: article.translate.xml:598 +msgid "" +"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." +msgstr "" +"O código de alocação de memória do FreeBSD implementa otimizações de page " +"coloring, o que significa que o código de alocação de memória tentará " +"localizar páginas livres contíguas do ponto de vista do cache. Por exemplo, " +"se a página 16 da memória física for atribuída à página 0 da memória virtual " +"de um processo e o cache puder conter 4 páginas, o código de page coloring " +"não atribuirá a página 20 da memória física a página 1 da memória virtual de " +"um processo. Em vez disso, atribui a página 21 da memória física. O código " +"de page coloring tenta evitar assimilar a página 20, porque ela é mapeada " +"sobre a mesma memória cache da página 16 e resultaria em um armazenamento " +"não otimizado. Este código adiciona uma quantidade significativa de " +"complexidade ao subsistema de alocação de memória de VM, como você pode " +"imaginar, mas o resultado vale o esforço. Page coloring torna a memória de " +"VM tão determinante quanto a memória física em relação ao desempenho do " +"cache." + +#. (itstool) path: sect1/title +#: article.translate.xml:615 +msgid "Conclusion" +msgstr "Conclusão" + +#. (itstool) path: sect1/para +#: article.translate.xml:617 +msgid "" +"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." +msgstr "" +"A memória virtual em sistemas operacionais modernos deve abordar vários " +"problemas diferentes de maneira eficiente e para muitos padrões de uso " +"diferentes. A abordagem modular e algorítmica que o BSD historicamente teve " +"nos permite estudar e entender a implementação atual, bem como substituir de " +"forma relativamente limpa grandes seções do código. Houve uma série de " +"melhorias no sistema de VM do FreeBSD nos últimos anos e o trabalho está em " +"andamento." + +#. (itstool) path: sect1/title +#: article.translate.xml:627 +msgid "Bonus QA session by Allen Briggs briggs@ninthwonder.com" +msgstr "" +"Sessão bônus de QA por Allen Briggs briggs@ninthwonder.com" + +#. (itstool) path: question/para +#: article.translate.xml:633 +msgid "" +"What is the interleaving algorithm that you refer to in your " +"listing of the ills of the FreeBSD 3.X swap arrangements?" +msgstr "" +"O que é o algoritmo de intercalação ao qual você se refere em " +"sua listagem dos males dos arranjos de swap do FreeBSD 3.X?" + +#. (itstool) path: answer/para +#: article.translate.xml:639 +msgid "" +"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:" +msgstr "" +"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 quatro áreas de troca " +"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:" + +#. (itstool) path: answer/literallayout +#: article.translate.xml:648 +#, no-wrap +msgid "A B C D A B C D A B C D A B C D" +msgstr "A B C D A B C D A B C D A B C D" + +#. (itstool) path: answer/para +#: article.translate.xml:650 +msgid "" +"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 (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." +msgstr "" +"O FreeBSD 3.X usa uma abordagem de lista sequencial de regiões " +"livres 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 (kern/subr_rlist.c). 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 " +"livres e C e D mostrados como todos alocados. " +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:662 +msgid "" +"Why do we interleave our swap space instead of just tack swap areas onto the " +"end and do something fancier? Because 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." +msgstr "" +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:668 +msgid "" +"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." +msgstr "" +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:678 +msgid "" +"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." +msgstr "" +"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." + +#. (itstool) path: question/para +#: article.translate.xml:691 +msgid "" +"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?" +msgstr "" +"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 systat -vm? As estatísticas do systat " +"rolam as páginas ativa e inativas juntas para a contagem de filas ativas?" + +#. (itstool) path: question/para +#: article.translate.xml:697 +msgid "I do not get the following:" +msgstr "Eu não entendo o seguinte:" + +#. (itstool) path: blockquote/para +#: article.translate.xml:700 +msgid "" +"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 systat -vm command." +msgstr "" +"É 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 systat -vm." + +#. (itstool) path: answer/para +#: article.translate.xml:712 +msgid "" +"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." +msgstr "" +"Sim, isto é confuso. A relação é meta versus " +"realidade. 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." + +#. (itstool) path: answer/para +#: article.translate.xml:717 +msgid "" +"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." +msgstr "" +"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 -> fila " +"inativa) quando o sistema não está sendo estressado, mesmo que não estejam " +"sendo usados." + +#. (itstool) path: question/para +#: article.translate.xml:727 +msgid "" +"In the ls1 / 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?" +msgstr "" +"No exemplo ls1 / vmstat 1, 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?" + +#. (itstool) path: answer/para +#: article.translate.xml:735 +msgid "" +"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." +msgstr "" +"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 faz pré-mapeamento de páginas que existem em seu " +"cache." + +#. (itstool) path: question/para +#: article.translate.xml:746 +msgid "" +"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?" +msgstr "" +"Em sua seção sobre otimizações de tabela de páginas, você pode dar um pouco " +"mais de detalhes sobre pv_entry e vm_page (ou vm_page deveria ser vm_pmap- 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?" + +#. (itstool) path: question/para +#: article.translate.xml:753 +msgid "" +"How does Linux do in the case where FreeBSD breaks down (sharing a large " +"file mapping over many processes)?" +msgstr "" +"Como o Linux faz no caso onde o FreeBSD quebra (compartilhando um grande " +"mapeamento de arquivos em muitos processos)?" + +#. (itstool) path: answer/para +#: article.translate.xml:758 +msgid "" +"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." +msgstr "" +"Uma vm_page representa uma tupla (objeto,índice#). Um " +"pv_entry 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 vm_page " +"e três estruturas pv_entry." + +#. (itstool) path: answer/para +#: article.translate.xml:766 +msgid "" +"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 (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 " +"pv_entry's associated with that vm_page to remove or modify the pte's from their page tables." +msgstr "" +"As estruturas pv_entry representam apenas as páginas " +"mapeadas pela MMU (uma pv_entry representa uma pte). Isso " +"significa que quando precisamos remover todas as referências de hardware " +"para uma vm_page (para reutilizar a página para outra " +"coisa, paginar, limpar, inativar e assim por diante), podemos simplesmente " +"escanear a lista encadeada de pv_entry associada a essa " +"vm_page para remover ou modificar os pte's de suas " +"tabelas de páginas." + +#. (itstool) path: answer/para +#: article.translate.xml:776 +msgid "" +"Under Linux there is no such linked list. In order 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." +msgstr "" +"No Linux, não existe essa lista vinculada. Para remover todos os mapeamentos " +"de tabelas de páginas de hardware para um vm_page, o " +"linux deve indexar em todos os objetos de VM que possam " +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:793 +msgid "" +"FreeBSD has added complexity (the pv_entry scheme) in " +"order to increase performance (to limit page table accesses to " +"only those pte's that need to be modified)." +msgstr "" +"O FreeBSD adicionou complexidade (o esquema pv_entry) " +"para aumentar o desempenho (para limitar os acessos da tabela de páginas a " +"somente aqueles pte's que precisam ser modificados)." + +#. (itstool) path: answer/para +#: article.translate.xml:798 +msgid "" +"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." +msgstr "" +"Mas o FreeBSD tem um problema de escalonamento que o Linux não possui, pois " +"há um número limitado de estruturas pv_entry e isso causa " +"problemas quando você tem um compartilhamento massivo de dados. Nesse caso, " +"você pode ficar sem estruturas pv_entry, mesmo que haja " +"bastante memória livre disponível. Isto pode ser corrigido com bastante " +"facilidade aumentando o número de estruturas pv_entry na " +"configuração do kernel, mas realmente precisamos encontrar uma maneira " +"melhor de fazê-lo." + +#. (itstool) path: answer/para +#: article.translate.xml:808 +msgid "" +"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." +msgstr "" +"Em relação à sobrecarga de memória de uma tabela de páginas verso do esquema " +"pv_entry: o Linux usa tabelas permanentes " +"que não são descartadas, mas não precisa de um pv_entry " +"para cada pte potencialmente mapeado. O FreeBSD usa tabelas de páginas " +"throw away, mas adiciona em uma estrutura pv_entry 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." + +#. (itstool) path: question/para +#: article.translate.xml:823 +msgid "" +"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." +msgstr "" +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:829 +msgid "" +"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!" +msgstr "" +"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 mesmo 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!" + +#. (itstool) path: answer/para +#: article.translate.xml:837 +msgid "" +"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." +msgstr "" +"Agora estou simplificando muito as coisas. O que acabei de descrever é o que " +"é chamado de cache de memória de hardware diretamente mapeado. 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." + +#. (itstool) path: answer/para +#: article.translate.xml:845 +msgid "" +"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." +msgstr "" +"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." + +#. (itstool) path: answer/para +#: article.translate.xml:851 +msgid "" +"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." +msgstr "" +"É extremamente importante… extremamente 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 " +"centenas 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) é lenta, quando comparada " +"à velocidade de um núcleo de processador moderno." + +#. (itstool) path: answer/para +#: article.translate.xml:863 +msgid "" +"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." +msgstr "" +"Ok, agora em page coloring: Todos os caches de memória modernos são " +"conhecidos como caches físicos. 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." + +#. (itstool) path: answer/para +#: article.translate.xml:869 +msgid "" +"But in the UNIX 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." +msgstr "" +"Mas no mundo UNIX 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 físicas 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 " +"física." + +#. (itstool) path: answer/para +#: article.translate.xml:878 +msgid "" +"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)." +msgstr "" +"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)." + +#. (itstool) path: answer/para +#: article.translate.xml:885 +msgid "" +"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." +msgstr "" +"É isso que o disfarce de página faz. Em vez de atribuir páginas físicas " +"aleatórias 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 " +"razoavelmente contíguas 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." + +#. (itstool) path: answer/para +#: article.translate.xml:895 +msgid "" +"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." +msgstr "" +"Note que eu digo razoavelmente contíguo ao invés de " +"simplesmente contíguo. 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 não 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." Property changes on: head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/x-gettext-translation; charset=UTF-8 \ No newline at end of property