Instituto de Matem´ atica e Estat´ıstica Departamento de Ciˆ encia da Computa¸ c˜ ao
Relat´ orio Cient´ıfico
Per´ıodo: Mar¸co/2002 - Agosto/2002
Bolsa de Mestrado - FAPESP
Cache Comprimido em Sistemas de Mem´ oria Virtual
Bolsista
Rodrigo Souza de Castro Orientador
Prof. Dr. Alair Pereira do Lago
Resumo do Projeto
Face ao impacto no desempenho dos programas, `a sua complexidade e `a n˜ao optimalidade das solu¸c˜oes existentes, o estudo da mem´oria virtual continua recebendo a aten¸c˜ao dos pesquisadores e desenvolvedores de sistemas operacionais. ´E particularmente importante o sistema de pagina¸c˜ao em disco, que lida com uma das maiores disparidades: a diferen¸ca entre os tempos de acesso `a mem´oria principal e aos discos.
Diversos estudos foram feitos a esse respeito, e o assunto foi retomado recentemente com maior for¸ca. Os principais argumentos desses estudos foram obtidos atrav´es de simula¸c˜oes baseadas em dados de um sistema real. Em 1999, Scott F. Kaplan [3] provou que atrav´es de um cache adaptativo de p´aginas comprimidas na mem´oria principal podemos ter ganhos de desempenho, pelo fato de se diminuir a pagina¸c˜ao em disco.
Esta t´ecnica torna-se atraente face `a perspectiva de que os custos de compress˜ao continuem diminuindo.
Isso deve-se essencialmente `a disparidade cada vez maior entre a velocidade dos processadores e latˆencia dos discos.
At´e hoje n˜ao se conhece nenhuma implementa¸c˜ao desse sistema de cache adaptativo de p´aginas compri- midas proposto por Wilson e Kaplan [13, 3] tampouco um estudo que, com base em uma implementa¸c˜ao real, caracterize cen´arios em que a compress˜ao tenha um impacto particularmente positivo ou negativo. Esse pro- jeto de pesquisa de mestrado visa um estudo rigoroso da literatura relativa ao problema e a implementa¸c˜ao das t´ecnicas e algoritmos estudados previamente, em especial a implementa¸c˜ao das id´eias propostas por Kaplan.
1 Plano de Trabalho (Inicial vs Realizado)
Legenda
Executado √
Parcialmente Executado ◦
A ser executado •
Atividades
1 disciplinas do programa de p´os-gradua¸c˜ao √
2 estudo de t´ecnicas de gerenciamento de mem´oria √
3 estudo do enfoque do gerenciamento de mem´oria do Linux 2.4 √
4 estudos das propostas decache comprimido √
5 estudo dos algoritmos de compress˜ao das p´aginas √
6 implementa¸c˜ao de prot´otipo para a cria¸c˜ao de estat´ısticas de compress˜ao no Linux √ 7 estudo sobre a inclus˜ao docache comprimido no c´odigo do Linux √ 8 estudo de parˆametros do sistema para o cache adaptativo √
9 cria¸c˜ao do projeto de implementa¸c˜ao √
10 implementa¸c˜ao de prot´otipo que n˜ao leva em conta parˆametros do sistema √ 11 avalia¸c˜ao da implementa¸c˜ao via “micro-benchmarks” ◦
12 reda¸c˜ao da proposta da disserta¸c˜ao √
13 exame de qualifica¸c˜ao √
14 primeiro estudo do impacto dessecache comprimido est´atico e primitivo √ 15 inser¸c˜ao no prot´otipo dos parˆametros de adaptabilidade ◦
16 segundo estudo do impacto docache comprimido ◦
17 caracteriza¸c˜ao de workloads favor´aveis e desfavor´aveis ◦ 18 reda¸c˜ao de relat´orios semestrais para a Fapesp ◦
19 reda¸c˜ao de eventuais artigos •
20 reda¸c˜ao da disserta¸c˜ao ◦
21 exame de disserta¸c˜ao •
2 Cronograma (Inicial vs Realizado)
Legenda
proposto executado √
parcialmente executado ◦ a ser executado • n˜ao ser´a executado × n˜ao proposto executado ?
a ser executado ·
2001/2002
Mar Abr Mai Jun Jul Ago Set Out Nov Dez Jan Fev
1 √ √ √ √ √ √ √ √
2 √
3 √ √ √ √
4 √
5 √
6 √
7 √
8 √ √
9 √ √
10 √ √ √
12 √
13 √
2002/2003
Mar Abr Mai Jun Jul Ago Set Out Nov Dez Jan Fev
10 √
11 ◦
14 √
15 √ √ √ √
◦
16 ◦
17 √
◦
18 ? × ? ×
19 • •
20 √ √ √
• • •
21 •
3 Principais Realiza¸ c˜ oes
3.1 Resumo
Essa se¸c˜ao visa apresentar um detalhamento das realiza¸c˜oes efetuadas no per´ıodo ao qual esse relat´orio se refere. Partindo do exame de qualifica¸c˜ao, mostraremos sucintamente cada uma das etapas que nos levaram ao atual estado do projeto.
O projeto, iniciado em janeiro de 2001, encontra-se atualmente no estado em que contamos com uma implementa¸c˜ao est´avel de um cache comprimido no kernel do sistema operacional Linux 2.4. O cache comprimido possui a caracter´ıstica de se adaptar ao comportamento do sistema, diminuindo ou aumentando o seu tamanho de acordo com a sua utilidade. Os resultados j´a obtidos atrav´es de testes de desempenho s˜ao bastante satisfat´orios, sendo que as altera¸c˜oes efetuadas no per´ıodo ao qual o relat´orio se refere exerceram uma grande influˆencia para esses resultados. Algumas mudan¸cas visando ainda melhor desempenho est˜ao sendo estudadas e efetuadas.
Para concluir, o nossos pr´oximos passos s˜ao efetuar verifica¸c˜oes e mudan¸cas finais no c´odigo, no que concerne `a estabilidade e ao desempenho; execu¸c˜ao de um conjunto de testes final; e a conclus˜ao da escrita da disserta¸c˜ao de mestrado.
3.2 Exame de Disserta¸ c˜ ao
No in´ıcio do per´ıodo ao qual esse relat´orio se refere, escrevemos a proposta de disserta¸c˜ao como requeri- mento do programa de mestrado. Ela foi submetida para a comiss˜ao de p´os-gradua¸c˜ao do IME-USP, tendo sido aprovada para o exame de qualifica¸c˜ao, que aconteceu no dia 29 de abril de 2002. Ele foi composto pela seguinte banca:
– Prof. Dr. Alair Pereira do Lago, IME - USP (orientador) – Prof. Dr. Edson Toshimi Midorikawa - Escola Polit´ecnica - USP – Prof. Dr. Fabio Kon - IME - USP
– Prof. Dr. Carlos Eduardo Ferreira - IME - USP (suplente)
A banca, ap´os a exposi¸c˜ao, aprovou o exame de qualifica¸c˜ao do aluno.
3.3 Exame de Proficiˆ encia em L´ıngua Estrangeira
Outro requerimento do programa de mestrado ´e o exame de proficiˆencia em l´ıngua estrangeira. A l´ıngua estrangeira escolhida foi inglˆes e esse exame foi feito com o Prof. Dr. Yoshiharu Kohayakawa no dia 26 de abril de 2002. O aluno foi aprovado no exame.
3.4 Semin´ arios em Sistemas de Computa¸ c˜ ao
Desde mar¸co de 2002, o aluno vem coordenando uma s´erie de semin´arios de p´os-gradua¸c˜ao sobre sistemas de computa¸c˜ao no IME - USP. Ele ´e respons´avel pela organiza¸c˜ao dos semin´arios [12] e o contato com os palestrantes, tendo obtido ´otimos resultados no primeiro semestre, em quest˜ao de um p´ublico muito maior que o obtido pelos semin´arios at´e ent˜ao, al´em de semin´arios variados. No dia 05 de abril de 2002, o aluno deu um semin´ario sobre o seu projeto nessa s´erie de semin´arios, apresentando todo o andamento do projeto e os resultados at´e aquele momento.
3.5 Algumas Defini¸ c˜ oes
Antes de descrever as realiza¸c˜oes do projeto, ´e interessante relembrarmos parte da terminologia introdu- zida em etapas anteriores deste projeto e que ser˜ao utilizadas ao longo desse relat´orio.
P´agina de Mem´oria Todo o espa¸co de endere¸camento de mem´oria do sistema ´e dividido em pequenas partes conhecidas como p´aginas. O tamanho das p´aginas ´e dependente da arquitetura de hardware que se est´a utilizando. Na arquitetura i386, o tamanho de p´agina ´e de 4 kilobytes.
P´agina de Mem´oria Suja/Limpa P´aginas de mem´oria podem sersujas oulimpas. P´aginas sujas neces- sitam ter os seus dados escritos em algum dispositivo que permita que esses dados possam ser recuperados.
Por sua vez, p´aginas limpas 1 j´a se encontram armazenadas em algum dispositivo que permita ao sistema recuper´a-las e n˜ao necessitam ser armazenadas novamente.
P´agina do Cache Comprimido Umap´agina do cache comprimido´e uma p´agina de mem´oria2utilizada para armazenar p´aginas de mem´oria comprimidas. O cache comprimido ´e composto por diversas p´aginas de mem´oria com esse fim. Elas n˜ao s˜ao necessariamente cont´ıguas pois podem ser alocadas em momentos distintos e dependem da configura¸c˜ao da mem´oria do sistema no momento da aloca¸c˜ao. P´aginas de mem´oria dispon´ıveis no sistema para os processos e para os caches do sistema de arquivos formam o que Kaplan definiu comocache n˜ao-comprimido.
Fragmento Uma p´agina de mem´oria armazenada em uma p´agina do cache comprimido ´e conhecida como um fragmento. Portanto, uma p´agina do cache comprimido possui um ou mais fragmentos, que podem estar comprimidos ou n˜ao. O caso em que se armazena uma p´agina de mem´oria no estado natural (i.e, n˜ao comprimido) acontece quando o resultado comprimido dos dados dessa p´agina ocupam um tamanho maior que o seu tamanho original. Os fragmentos tamb´em s˜ao diferenciados por serem sujos (ou seja, a p´agina original era considerada suja) ou limpos (a p´agina que lhe deu origem era limpa). Caso necessite liberar espa¸co no cache comprimido, fragmentos limpos s˜ao simplesmente liberados enquanto os sujos s˜ao escritos nos seus respectivos dispositivos.
3.6 Melhoramentos
Tendo como motiva¸c˜ao os resultados n˜ao satisfat´orios obtidos no teste de compila¸c˜ao do kernel do Linux at´e mar¸co de 2002, o pr´oximo passo foi estudar qual era a causa desse mau desempenho e tentar melhor´a-lo.
O primeiro problema encontrado com a an´alise dos dados de desempenho foi o ambiente em que os testes eram rodados. As execu¸c˜oes iniciais eram rodadas em ambientes que simulavam uma m´aquina virtual, que apesar de serem bastante ´uteis para a descoberta de erros de programa¸c˜ao, n˜ao eram acurados o suficiente nos seus dados de modo a permitir uma an´alise correta dos dados. Essas ferramentas foram abandonadas depois de nos levar a diversas d´uvidas que contrariavam a teoria.
A seguir, notamos que se o kernel tivesse com recursos comoprofilingativados, o seu desempenho tamb´em sofreria altera¸c˜oes. Esses recursos foram cuidadosamente desativados.
Novas estat´ısticas foram coletadas, com separa¸c˜ao por cache (swap cache ou page cache). Uma nova entrada (comp cache hist) no diret´orio /proc foi criada cuja sa´ıda era a situa¸c˜ao do cache comprimido
1P´aginas limpas podem ter tido os seus dados alterados e n˜ao se encontrar em algum dispositivo, mas nesse caso, as opera¸c˜oes de entrada e sa´ıda s˜ao feitas atrav´es de estruturas conhecidas por buffers. Aqui desconsideramos as p´aginas com buffers pois nesse caso s˜ao os buffers que ficam sujos ou limpos.
2Na verdade, durante esse relat´orio veremos que uma das mudan¸cas efetuadas foi a possibilidade de usarmos mais p´aginas de mem´oria cont´ıguas para resolver problemas como a melhor utiliza¸c˜ao do espa¸co dentro do cache comprimido
no momento. Veja abaixo um exemplo de sa´ıda desse arquivo, que exibe o n´umero de p´aginas do cache comprimido que tem determinado espa¸co livre cont´ıguo (linhas) pelo n´umero de fragmentos que a p´agina do cache comprimido cont´em (colunas). As linhas exibem faixas de valores em bytes e as colunas o n´umero de fragmentos.
compressed cache - free space histogram (free space x number of fragments)
total 0f 1f 2f 3f 4f 5f 6f more
0: 4 0 0 0 3 0 0 0 1
1 - 400: 523 0 0 0 410 52 22 12 27
401 - 800: 41 0 0 0 36 1 0 2 2
801 - 1200: 1 0 0 0 1 0 0 0 0
1201 - 1600: 0 0 0 0 0 0 0 0 0
1601 - 2000: 118 0 0 117 0 0 0 0 1
2001 - 2400: 718 0 0 707 4 5 0 0 2
2401 - 2800: 22 0 0 22 0 0 0 0 0
2801 - 3200: 0 0 0 0 0 0 0 0 0
3201 - 3600: 0 0 0 0 0 0 0 0 0
3601 - 4000: 0 0 0 0 0 0 0 0 0
4001 - 4400: 0 0 0 0 0 0 0 0 0
4401 - 4800: 0 0 0 0 0 0 0 0 0
4801 - 5200: 0 0 0 0 0 0 0 0 0
5201 - 5600: 1 0 1 0 0 0 0 0 0
5601 - 6000: 0 0 0 0 0 0 0 0 0
6001 - 6400: 0 0 0 0 0 0 0 0 0
6401 - 6800: 0 0 0 0 0 0 0 0 0
6801 - 7200: 0 0 0 0 0 0 0 0 0
7201 - 7600: 0 0 0 0 0 0 0 0 0
7601 - 8000: 0 0 0 0 0 0 0 0 0
8001 - 8192: 0 0 0 0 0 0 0 0 0
Analisando os dados de execu¸c˜oes e efetuando uma verifica¸c˜ao atenciosa do c´odigo, tamb´em foi observado que eram efetuadas muito mais leituras do disco com o cache comprimido. Um dos culpados era uma falha conceitual da implementa¸c˜ao na qual, caso uma p´agina fosse lida do cache comprimido, era efetuado uma leitura readahead de diversas p´aginas armazenadas em posi¸c˜oes subsequentes no dispositivo de armazena- mento. O conceito de readahead se aplica somente a p´aginas armazenadas em disco, pois se faz uso da opera¸c˜ao de leitura para ler diversos blocos ao mesmo tempo, visto que ´e prov´avel que os pr´oximos blocos sejam utilizados em um futuro recente. Esse conceito se aplica tanto a p´aginas lidas do swap assim como do page cache e o conserto foi certificar que essa leiturareadhead somente fosse feita para p´aginas que tivessem que ser lidas do disco.
Quando uma determinada p´agina, em uma leitura dereadahead, j´a se encontra na mem´oria, nada ´e feito.
No entanto, com o cache comprimido, durante uma leitura dereadahead, caso a p´agina se encontrasse com- primida, ela seria descomprimida e armazenada no cache n˜ao-comprimido, alterando, portanto, a ordem LRU das p´aginas na mem´oria. Como ´e conceitualmente errado, foi consertado esse erro ao n˜ao se descomprimir mais p´aginas caso fosse uma leiturareadhead.
No Linux, existem marcas d’´agua das p´aginas livres, ou seja, limites para manter um certo n´umero de p´aginas livres para usos mais imediatos pelo pr´oprio kernel. Dessa maneira, o kernel, sempre que o n´umero de p´aginas livres estiver abaixo desses limites, executa o c´odigo para libera¸c˜ao de mem´oria. Com o cache comprimido, a quantidade de mem´oria para o restante da mem´oria (ou seja, o cache n˜ao-comprimido) ´e menor que o total de mem´oria no sistema, no entanto, as marcas d’´agua eram calculadas sobre o total. A
conseq¨uˆencia ´e que o cache n˜ao-comprimido ficava sobre uma press˜ao muito maior que o que seria esperado para o seu tamanho, o que ocasionava, em muitos casos, a press˜ao maior em todo o sistema.
Outras altera¸c˜oes tamb´em influenciaram o desempenho do sistema, como a aloca¸c˜ao de determinadas estruturas somente quando fossem ser utilizadas (como as estruturas do virtual swap) e a reescrita de de- terminados caminhos cr´ıticos do cache comprimido, notadamente o caminho executado quando precisa-se liberar espa¸co no cache.
3.7 Suporte a p´ aginas com buffers
Atrav´es de an´alises dos dados de execu¸c˜ao, foi observado que, com o cache comprimido, muitas opera¸c˜oes de entrada e sa´ıda era causadas por escrita de buffers sujos das p´aginas. As raz˜oes s˜ao: (1) p´aginas com buffers n˜ao eram armazenadas no cache comprimido; (2) o cache n˜ao-comprimido tinha uma press˜ao muito maior de mem´oria em rela¸c˜ao ao sistema sem cache comprimido (obviamente pelo fato de ser menor).
Decidimos ent˜ao prover um suporte a p´aginas com buffers com o objetivo de diminuir a limpeza de buffers e assim diminuir as escritas durante a execu¸c˜ao do kernel com cache comprimido. Esse suporte foi implementado, e p´aginas com buffers come¸caram a ser armazenadas no cache comprimido, mas sem serem comprimidas pois elas s˜ao acessadas diretamente pelo c´odigo de buffers. Comprimi-las n˜ao traria ajuda, pois elas certamente seriam escritas em breve pelo sistema de buffers, e o fato de estar comprimido levaria a uma descompress˜ao em seguida para poder permitir a escrita (todos os buffers sujos do sistema s˜ao escritos em disco de tempos em tempos).
Testes executados mostraram uma diminui¸c˜ao do n´umero de escritas, mas isso n˜ao se traduzia em melhoria do desempenho. Al´em disso, as altera¸c˜oes no c´odigo para a inserta¸c˜ao desse tipo de p´agina foram grandes e muito intrusivas, que por fim esse suporte foi removido.
3.8 Cache Comprimido de Tamanho Fixo Pr´ e-Alocado
Aplica¸c˜oes reais tˆem, em geral, necessidades de mem´oria vari´avel durante a sua execu¸c˜ao. Notamos isso sobretudo no teste de compila¸c˜ao do Kernel do Linux com o aux´ılio de sa´ıdas peri´odicas do arquivo /proc/comp cache hist. Para determinados tamanhos do cache comprimido de tamanho fixo (pr´e-alocado na hora do boot) e da mem´oria do sistema, observa-se que durante um tempo substancial da execu¸c˜ao desse teste o cache comprimido n˜ao est´a completamente usado. Ou seja, as suas p´aginas pr´e-alocadas n˜ao tˆem utilidade durante boa parte da execu¸c˜ao da aplica¸c˜ao.
Aqui tamb´em ´e importante observar que essas p´aginas, al´em de n˜ao ter utilidade, ainda influenciam de modo bastante incisivo no desempenho do sistema. O fato de elas estarem alocadas – e n˜ao trazerem qualquer benef´ıcio para o sistema – resulta que a quantidade de mem´oria dispon´ıvel para o cache n˜ao-comprimido
´
e menor. Isso implica que a press˜ao de mem´oria ´e muito maior do que seria se houvesse mais p´aginas dispon´ıveis para o cache n˜ao-comprimido, dispendendo parte do tempo de execu¸c˜ao das aplica¸c˜oes no c´odigo de libera¸c˜ao de mem´oria do sistema de mem´oria virtual, al´em de for¸car um n´umero maior de escritas de p´aginas atrav´es do seu sistema de buffers.
Em termos pr´aticos, para testes mais realistas como a compila¸c˜ao do Kernel do Linux, notamos que o Kernel do Linux com o uso do cache comprimido n˜ao conseguia ter um desempenho melhor que o Kernel do Linux padr˜ao. No m´aximo, conseguia-se ter um desempenho parecido, com pouco ou nenhum preju´ızo.
Atrav´es dessa an´alise chegamos `a conclus˜ao que o cache comprimido de tamanho fixo pr´e-alocado, apesar de ter um desempenho muito bom para determinadas aplica¸c˜oes 3, n˜ao ´e a configura¸c˜ao adequada para o seu uso de prop´osito geral.
3No relat´orio anterior exibimos algumas aplica¸c˜oes com desempenhos muito bons com o cache comprimido de tamanho fixo pr´e-alocado.
3.9 Redimensionamento por “Demanda”
Tendo em vista a conclus˜ao que o cache comprimido de tamanho fixo pr´e-alocado n˜ao era a configura¸c˜ao ideal, resolvemos implementar uma pol´ıtica que n˜ao pr´e-alocasse o cache comprimido. A id´eia consiste em ter um cache comprimido com uma pequena quantidade de p´aginas, somente o necess´ario para permitir algumas libera¸c˜oes de p´aginas e evitar falhas de aloca¸c˜ao ao crescer. A partir desse tamanho inicial, na medida em que for solicitado, ele vai crescendo at´e o tamanho m´aximo definido. O cache comprimido s´o cresce quando
´
e necess´ario, ou seja, quando o sistema de mem´oria virtual est´a sob press˜ao e ´e necess´ario comprimir uma p´agina, mas n˜ao h´a espa¸co no cache comprimido.
Uma vez o ´ultimo fragmento de uma p´agina ´e liberado, seja por ter sido escrito (fragmento sujo), por ter sido liberado (fragmento limpo) ou ainda por ter sido descomprimido e devolvido ao sistema, a(s) p´agina(s) de mem´oria usadas pela p´agina do cache comprimido ´e(s˜ao) liberada(s) e o cache comprimido diminui de tamanho.
Essa pol´ıtica nos permitiu chegar a bons resultados. O teste de compila¸c˜ao do Kernel do Linux, somente com essas mudan¸cas, come¸cou a ter tempos de execu¸c˜ao melhores que o Kernel do Linux padr˜ao.
3.10 Compacta¸ c˜ ao de Fragmentos
Ao longo da utiliza¸c˜ao do cache comprimido, uma certa fragmenta¸c˜ao da mem´oria utilizada nas p´aginas do cache comprimido acontece pois fragmentos n˜ao adjacentes ao espa¸co livre cont´ıguo no final da p´agina do cache comprimido podem ser removidos antes que o ´ultimo fragmento. O espa¸co antes utilizados por estes fragmentos ficam sem uso pelo fato de haver outros fragmentos entre eles e o espa¸co livre cont´ıguo. Como o custo de movimentar os fragmentos dentro da p´agina ´e muito grande se for executado a cada remo¸c˜ao de fragmento, essa fragmenta¸c˜ao acaba ocorrendo de qualquer forma em maior ou menor grau dependendo do tipo de acesso aos fragmentos do cache comprimido. Quanto menor a fragmenta¸c˜ao, mais bem utilizado ´e o espa¸co reservado para o cache comprimido.
Oespa¸co livre cont´ıguo (em geral no final) de uma p´agina do cache comprimido ´e o espa¸co n˜ao-utilizado para o armazenamento de fragmentos. `A medida que fragmentos adjacentes a esse espa¸co livre s˜ao liberados, o espa¸co livre ´e incrementado. E assim que novos fragmentos s˜ao armazenados nessa p´agina do cache comprimido, o espa¸co livre ´e decrementado. ´E baseado no valor de espa¸co livre que se ´e escolhido em qual p´agina do cache comprimida ser´a armazenado um fragmento. Oespa¸co livre fragmentado consiste da soma dos espa¸cos livres no p´agina que n˜ao foram unidos ao espa¸co livre cont´ıguo para poderem ser utilizados.
Uma outra nova entrada (comp cache frag) no diret´orio /proc foi criada para exibir o espa¸co livre fragmentado nas p´aginas do cache comprimido. Abaixo est´a um exemplo de sa´ıda desse arquivo, que exibe o n´umero de p´aginas do cache comprimido que tem determinado espa¸co livre cont´ıguo (linhas) pelo espa¸co livre fragmentado (colunas). As linhas e as colunas exibem faixas de valores em bytes.
compressed cache - fragmentation histogram (free space x fragmented space)
total <500 -1000 -1500 -2000 -2500 -3000 -3500 -4000 -4096
1 - 200: 1411 537 22 6 6 275 257 198 110 0
201 - 400: 67 33 0 0 0 3 13 18 0 0
401 - 600: 6 3 0 0 0 0 3 0 0 0
601 - 800: 3 2 0 0 0 0 0 1 0 0
801 - 1000: 1 1 0 0 0 0 0 0 0 0
1001 - 1200: 3 3 0 0 0 0 0 0 0 0
1201 - 1400: 39 39 0 0 0 0 0 0 0 0
1401 - 1600: 35 35 0 0 0 0 0 0 0 0
1601 - 1800: 56 56 0 0 0 0 0 0 0 0
1801 - 2000: 103 103 0 0 0 0 0 0 0 0
2001 - 2200: 6 6 0 0 0 0 0 0 0 0
2201 - 2400: 0 0 0 0 0 0 0 0 0 0
2401 - 2600: 0 0 0 0 0 0 0 0 0 0
2601 - 2800: 0 0 0 0 0 0 0 0 0 0
2801 - 3000: 0 0 0 0 0 0 0 0 0 0
3001 - 3200: 0 0 0 0 0 0 0 0 0 0
3201 - 3400: 0 0 0 0 0 0 0 0 0 0
3401 - 3600: 0 0 0 0 0 0 0 0 0 0
3601 - 3800: 0 0 0 0 0 0 0 0 0 0
3801 - 4000: 0 0 0 0 0 0 0 0 0 0
4001 - 4096: 0 0 0 0 0 0 0 0 0 0
Com sa´ıdas peri´odicas do/proc/comp cache frag durante a execu¸c˜ao de alguns testes, verificamos que havia uma grande inutiliza¸c˜ao do cache comprimido em determinados momentos devido `a fragmenta¸c˜ao den- tro das p´aginas do cache (a sa´ıda acima exibe essa inutiliza¸c˜ao). Essa inutiliza¸c˜ao for¸cava uma desnecess´aria libera¸c˜ao de fragmentos e escrita em disco, que degradava o desempenho do sistema com cache comprimido.
De modo a solucionar o problema, buscamos uma solu¸c˜ao que n˜ao incorresse no custo de movimentar os fragmentos finais durante qualquer remo¸c˜ao de um fragmento interno de uma p´agina do cache comprimido.
Dessa maneira, come¸camos a controlar, al´em do espa¸co livre cont´ıguo na p´agina do cache comprimido, tamb´em o espa¸co livre fragmentado nela. Quando n˜ao se encontrasse espa¸co no cache comprimidosem ter que movimentar fragmentos, procurava-se alguma p´agina do cache comprimido que possuisse espa¸co total (i.e, fragmentado + cont´ıguo) suficiente para armazenar esse novo fragmento. Nesse caso, os fragmentos eram movimentados para que todo o espa¸co livre fosse cont´ıguo na parte final da p´agina do cache comprimido.
Essa opera¸c˜ao ´e conhecida comocompacta¸c˜ao dos fragmentos.
3.11 P´ aginas do Cache Comprimido de Tamanhos Maiores
Atrav´es das an´alises de desempenho, tamb´em foi observado que em alguns casos, a taxa de compress˜ao m´edia n˜ao ´e muito grande, comprimindo uma p´agina para valores como 50% a 60% do seu tamanho, em m´edia. Nesses casos, uma p´agina do cache comprimido de tamanho de uma p´agina de mem´oria (4096 bytes para arquitetura i386), na m´edia, s´o armazena um fragmento, situa¸c˜ao bastante desfavor´avel para o uso do cache comprimido pois na pr´atica ele n˜ao oferece vantagem em rela¸c˜ao ao sistema sem o seu uso.
Para amenizar esse problema de baixa taxa de compress˜ao, foi implementado o suporte a p´aginas do cache comprimido com o dobro do tamanho da p´agina de mem´oria padr˜ao (8192 bytes para a arquitetura i386) dentro do cache comprimido. Portanto, ao alocar mem´oria para o cache comprimido, alocamos duas p´aginas de mem´oria cont´ıguas (dentro do espa¸co de endere¸camento reservado `as estruturas internas ao kernel).
Apesar de por um lado ser interessante ter o cache comprimido formado por p´aginas desse tamanho e at´e de tamanhos maiores, por outro lado temos o problema de aloca¸c˜ao dessas p´aginas com o redimensionamento por “demanda”. Quanto maior o n´umero de p´aginas cont´ıguas a serem alocadas, maior ´e a probabilidade de n˜ao se conseguir alocar devida `a fragmenta¸c˜ao de mem´oria (observe que ´e diferente da fragmenta¸c˜ao explanada acima). Testes com p´aginas do dobro do tamanho tiveram um desempenho melhor que as p´aginas de tamanho simples, mas ainda alguns testes precisam ser feitos para verificar qual ´e o melhor tamanho. ´E ainda necess´ario averiguar se p´aginas maiores v˜ao ter tantos problemas de aloca¸c˜ao conforme esperamos.
3.12 Infra-estrutura para SMPs e preempted kernels
Um novo recurso do c´odigo foi a inclus˜ao da infra-estrutura necess´aria de sincroniza¸c˜ao para sistemas SMPs (SymmetricMultiProcessor) e kernels com recursos de maior “preemp¸c˜ao” (como os patchespreempte lockbreak, de Robert Love [11]). Esse recurso envolveu algumas altera¸c˜oes estruturais, pois o c´odigo anterior
n˜ao estava preparado por ter sido feito com a suposi¸c˜ao que n˜ao seria interrompido involuntariamente (a n˜ao ser no tratamento de interrup¸c˜oes).
Foram inclu´ıdos alguns contadores atˆomicos e spinlocks que permitiram que o c´odigo funcionasse com kernels com “preemp¸c˜ao”. Ele ainda n˜ao foi testado em um sistema SMP, que possui maior concorrˆencia real, e estamos certos que essa infra-estrutura pode ser otimizada para melhor desempenho para qualquer um dos casos (SMP oupreempt kernels). Apesar disso, ele foi bem testado com os patches de Robert Love e funcionou estavelmente.
3.13 Adaptabilidade
Efetuamos profundo estudo do artigo e tese de doutorado de Scott Kaplan, chegando a algumas conclus˜oes a respeito do c´alculo de custo-benef´ıcio proposto por ele e sobre as simula¸c˜oes que o levaram a considerar o cache comprimido interessante atualmente. Primeiramente, n˜ao h´a infra-estrutura atual de software nem de hardware na arquitetura i386 para a coleta dos dados necess´arios para esse c´alculo de custo-benef´ıcio. Uma infra-estrutura somente por software (ou seja, altera¸c˜oes no sistema operacional) n˜ao seria de modo algum eficiente pois precisaria contar, ou pelo menos estimar com m´edio a alto grau de confian¸ca, o n´umero de acessos `as p´aginas na sua ordem LRU na mem´oria.
Nas simula¸c˜oes efetuadas por Kaplan n˜ao ´e computado o custo de armazenamento na mem´oria desses novos dados. As simula¸c˜oes dele, na verdade, n˜ao levam em conta nenhum custo de mem´oria para os metadados do cache comprimido. Entretanto, o uso de mem´oria para metadados diminui a quantidade de mem´oria dispon´ıvel para a execu¸c˜ao de programas e notamos que, em alguns casos, o que ´e considerado na teoria como um custo desprez´ıvel, na pr´atica pode exercer grande influˆencia no desempenho do sistema.
Em um sistema real como o Linux, o n´umero de p´aginas de mem´oria para as p´aginas de dados na mem´oria (in-memory data, segundo terminologia do Kaplan, ou p´aginas anˆonimas, no Linux) varia, pois o sistema operacional atribui as p´aginas segundo a necessidade, sejam para o pr´oprio kernel, para cache de p´aginas de arquivos ou para p´aginas de dados na mem´oria. Kaplan sup˜oe que o n´umero de p´aginas para dados na mem´oria ´e fixo, o que ´e incorreto para uma an´alise real.
Tamb´em n˜ao ´e considerado o impacto que o uso de parte da mem´oria para o cache comprimido faria sobre outros tipos de p´aginas, como p´aginas armazenando dados de arquivo. Ao se utilizar parte da mem´oria para o cache comprimido, diminui-se o espa¸co para esses outros tipos de p´aginas. Como em aplica¸c˜oes de mundo real, observa-se que ´e muito improv´avel chegarmos a 50 ou 60% de p´aginas com dados da mem´oria, a diminui¸c˜ao da mem´oria para outros tipos de p´aginas, notadamente p´aginas de arquivos, podem ter um impacto negativo no uso do cache comprimido, que eventualmente pode ser maior que o benef´ıcio trazido pelo ele.
Overheadsinerentes `a execu¸c˜ao do cache comprimido, sobretudo da adaptabilidade, n˜ao s˜ao considerados em nenhuma simula¸c˜ao. Esses overheads, na pr´atica, exercem uma grande influˆencia no desempenho do sistema. Como exemplos temos custos de aloca¸c˜ao de mem´oria para mudan¸ca do tamanho do cache (na adaptabilidade) e custos de gerenciamento interno do cache comprimido.
Na sua pol´ıtica de adaptabilidade, Kaplan prop˜oe alguns tamanhos de cache comprimido para as suas simula¸c˜oes. Se a sua pol´ıtica verifica que o cache comprimido n˜ao ´e interessante para o sistema, ele diminui at´e o seu tamanho m´ınimo (10% do tamanho da mem´oria), mas o cache comprimido ainda ´e utilizado e ainda
´
e um n´ıvel no sistema de mem´oria virtual. Em situa¸c˜oes em que o cache comprimido tem pouca utilidade para o sistema (nenhum ou poucos fragmentos s˜ao lidos), uma grande quantidade de p´aginas pode ser inutilmente comprimida, o que pode adicionar um enorme overhead ao sistema. Mesmo que essas p´aginas n˜ao fossem comprimidas, situa¸c˜oes como essas adicionam o overhead de copiar os dados para o cache comprimido e gerenciar a escrita dos fragmentos (ou somente libera¸c˜ao desses, se limpos). Esse tipo de cen´ario n˜ao ´e considerado por Kaplan em suas simula¸c˜oes.
A id´eia de adaptabilidade proposta, entretanto, foi verificada em nossos testes como sendo necess´aria
para o bom desempenho do cache comprimido. Como citado acima, observamos que, em alguns testes como a compila¸c˜ao do kernel, o uso do cache comprimido de tamanho fixo pr´e-alocado na mem´oria n˜ao trazia benef´ıcios, al´em de prejudicar o desempenho em diversas situa¸c˜oes. O uso de uma pol´ıtica bastante simples de adaptabilidade, que foi o redimensionamento por “demanda”, j´a melhorou de maneira significativa o desempenho em rela¸c˜ao ao cache comprimido de tamanho fixo pr´e-alocado.
Uma pol´ıtica mais avan¸cada de adaptabilidade que implementamos foi a divis˜ao das p´aginas dentro do cache comprimido em duas listas, chamadas deativaeinativa. A primeira armazena aproximadamente as p´aginas mais recentemente adicionadas ao cache comprimido e que, sem o cache comprimido, estariam na mem´oria. E na segunda, as p´aginas que se est˜ao sendo armazenadas na mem´oria devido `a compress˜ao. O tamanho de cada lista ´e calculado em fun¸c˜ao da taxa de compress˜ao efetiva, ou seja, quantos fragmentos est˜ao armazenados no cache comprimido em fun¸c˜ao do seu tamanho em n´umero de p´aginas de mem´oria.
O tamanho do cache se adapta de acordo com os acessos a p´aginas das duas listas. Se h´a muitos acessos a p´aginas da listaativae pouco a p´aginas da listainativa, ent˜ao o cache comprimido ´e reduzido. Por outro lado, caso existam muitos acessos a p´aginas da lista inativa, ent˜ao o crescimento ´e liberado (para crescer por “demanda”).
Os melhores parˆametros para caracterizar o que vanham a ser “muitos acessos” e como ser´a feito a redu¸c˜ao est˜ao sendo decididos atrav´es de experimenta¸c˜oes. Os resultados at´e o momento nos mostraram desempenhos muito bons para essa pol´ıtica, conforme se ver´a a seguir, nas estat´ısticas de desempenho.
3.14 Swap Comprimido
A fim de melhorar o desempenho, foi implementado o recurso de escrever as p´aginas no swap no formato comprimido, ao inv´es de descomprimi-la, como era feito at´e o momento. Dessa maneira, a descompress˜ao ´e adiada ao m´aximo para que seja somente feita se necess´aria. Como n˜ao houve custo significativo de mem´oria para esse suporte, visto que os metadados mais custosos s˜ao armazenados no disco, essa implementa¸c˜ao tornou-se padr˜ao no c´odigo do cache comprimido. ´E importante notar que somente p´aginas do swap cache podem ser armazenadas comprimidas.
Outra id´eia relacionada foi a implementa¸c˜ao da compacta¸c˜ao dos fragmentos comprimidos no swap. O objetivo ´e a diminui¸c˜ao do n´umero de opera¸c˜oes de escrita, mas nem sempre isso ´e poss´ıvel pois o custo dos metadados na mem´oria pode ser bastante significativo. Esse custo ´e em fun¸c˜ao do tamanho do swap e, dependendo da situa¸c˜ao, a economia de escritas em disco pode n˜ao compens´a-lo. Ainda n˜ao chegamos a um consenso se vale a pena a inclus˜ao dessa implementa¸c˜ao como padr˜ao do cache comprimido e nem se essa id´eia pode ser mais desenvolvida, por isso ´e uma op¸c˜ao de configura¸c˜ao no momento.
3.15 Caracteriza¸ c˜ ao de Workloads Desfavor´ aveis
Na etapa de caracteriza¸c˜ao deworkloadsfavor´aveis e desfavor´aveis, observamos o pior caso para o uso do cache comprimido. Ele ocorre quando as p´aginas s˜ao pouco utilizadas – e at´e n˜ao utilizadas – pelo sistema.
Dessa maneira, as p´aginas s˜ao comprimidas e n˜ao tem nenhuma utilidade, pois n˜ao chegam a ser lidas pelo sistema enquanto est˜ao presentes no cache comprimido. Por conseq¨uˆencia, elas s˜ao liberadas e o tempo de compress˜ao e o custo de gerenciamento, por fim afetam negativamente o desempenho do sistema.
Acreditamos que workloads com estas caracter´ısticas n˜ao sejam muito frequentes e que n˜ao h´a como reverter esse quadro desfavor´avel pois o cache comprimido se trata de um novo n´ıvel no sistema de mem´oria virtual pelo qual as p´aginas de mem´oria devem passar. Achamos que no m´aximo podemos diminuir o preju´ızo, possivelmente atrav´es da pol´ıtica de n˜ao comprimir p´aginas quando se detecta essa situa¸c˜ao. Como em geral ´e mais comum acontecer com p´aginas limpas, estamos direcionando o estudo para tentar desenvolver pol´ıtica que diminua o preju´ızo nesse caso.
3.16 Visibilidade
O projeto continua com bastante visibilidade na comunidade de software livre e do pr´oprio Linux. A p´agina do projeto [6] possui uma se¸c˜ao de estat´ısticas [2] que efetua a contabilidade de acessos edownloadsdos arquivos do projeto. Nessa p´agina ´e poss´ıvel verificar que o projeto soma 49 milpage views e o c´odigo-fonte do projeto foi baixado 3100 vezes (dados at´e dia 06/Set/2002).
O Kernel do Linux [5], al´em da sua vers˜ao oficial, conhecida porvanillaoustockkernel, possui tamb´em diversos projetos que inserem novas funcionalidades ou corrigem bugs, mas que n˜ao foram inclu´ıdos na vers˜ao oficial. Esses projetos distribuem o seu c´odigo-fonte atrav´es de um arquivo que armazena altera¸c˜oes em rela¸c˜ao do Kernel oficial, chamados depatches. Como n˜ao s˜ao inclu´ıdos na vers˜ao oficial, s˜ao chamados depatchesn˜ao-oficiais e muitas vezespatchesn˜ao-oficiais interessantes s˜ao agrupados em conjuntos depatches oupatchsets.
Opatch do projeto cache comprimido ´e inclu´ıdo por dois projetos que distribuem conjuntos depatches:
Working Overloaded Linux Kernel [14], mantido por Marc-Christian Petersen, e Performance Patches [1], de Con Kolivas. A inclus˜ao nesses projetos geram retorno por uma maior base de usu´arios e demonstra que h´a um interesse da comunidade pelo projeto.
3.17 Estat´ısticas de Desempenho
Aqui vamos apresentar algumas estat´ısticas dos testes de desempenho que foram executados ao longo do nosso desenvolvimento recente. O cache comprimido utilizado para esses testes possui as mais recentes pol´ıticas de adaptabilidade e a sua configura¸c˜ao ´e apresentada a seguir.
– Suporte aoPage Cache
– Suporte a P´aginas do Cache Comprimido de Tamanho Maior – Algoritmo de Compress˜ao: LZO
O computador em que rodamos os testes ´e um Pentium III 1 GHz, com 768 megabytes de mem´oria RAM e 1 gigabyte de parti¸c˜ao de swap. A distribui¸c˜ao Linux ´e a Debian Woody 3.0. No desenvolvimento recente, procuramos focar em aplica¸c˜oes reais para verificar o desempenho do cache comprimido. Entre elas, aqui apresentamos:
Compila¸c˜ao do Kernel do Linux
Executar a compila¸c˜ao do Kernel do Linux [5] ´e amplamente usada para medir o desempenho do sistema de mem´oria virtual e possui caracter´ısticas bastante particulares. Entre eles, um alto uso de CPU e do sistema de mem´oria virtual, principalmente quando aumenta-se a concorrˆencia entre as compila¸c˜oes dos diversos arquivos. Compilamos o Kernel do Linux vers˜ao 2.4.18 [4] com a sua configura¸c˜ao padr˜ao para arquitetura i386. Utilizamos trˆes n´ıveis de concorrˆencia durante a execu¸c˜ao desse teste que aqui expressamos pelos parˆametros passados ao GNU Make: -j1, que executa apenas um job; -j2, que executa dois jobs simultaneamente; e-j4, que executa quatrojobs simultaneamente.
Open Source Database Benchmark
OOpen Source Database Network[8] ´e umbenchmark que faz testes com opera¸c˜oes de bancos de dados. O primeiro motivo pelo qual esse teste ´e considerado ´e o fato de terem sido rodados testes de banco de dados na implementa¸c˜ao feita Fred Douglis do cache comprimido e em todos os testes Douglis obteve maus resultados. Em segundo lugar, visto que bancos de dados s˜ao comumente utilizados por diversos segmentos de usu´arios de sistemas operacionais, ´e importante verificar o impacto que o cache comprimido pode ter nesse importante tipo de aplicativo computacional.
Foi rodado aqui esse benchmark utilizando-se o gerenciador de banco de dadosPostgreSQL[10], com um banco de dados de 40 megabytes dispon´ıvel na p´agina de arquivos do projeto OSDB [9].
MUMmer
O MUMmer [7] ´e uma aplica¸c˜ao cient´ıfica que produz alinhamento de genomas e faz um uso intenso de mem´oria. Os genomas comparados nos nossos testes s˜ao de duas esp´ecies deXanthomonas recentemente sequenciadas pelo projeto Genoma-FAPESP. Os arquivos dos genomas tem aproximadamente 5 megabytes de tamanho cada, e essa aplica¸c˜ao utiliza entre 400 e 420 megabytes de mem´oria durante a execu¸c˜ao.
Gr´aficos e Conclus˜ao
Os gr´aficos a seguir exibem resultado muito animadores para o desempenho do nosso projeto. Em parti- cular, nota-se que a pol´ıtica de adaptabilidade implementada est´a obtendo desempenho bastante interessante face `as aplica¸c˜oes que experimentamos.
0 50 100 150 200 250 300 350 400 450 500
18 24 30 36 42 48
Tempo de Execucao (segundos)
Memoria do Sistema (megabytes) Compilacao do Kernel do Linux (-j1)
Pentium III 1 GHz Algoritmo de Compressao: LZO
Suporte ao Page Cache Tamanho Duplo de Pagina
Cache Comprimido 2.4.18-0.24pre4 Linux Kernel Vanilla 2.4.18
Figura 1: Teste da Compila¸c˜ao do Kernel do Linux (-j1)
Ainda temos situa¸c˜oes em que o cache comprimido tem um desempenho pior que o Kernel do Linux padr˜ao. Uma delas acontece na compila¸c˜ao do Kernel do Linux com o n´ıvel de concorrˆencia -j4 (Fig. 3), onde no caso de 48 megabytes temos uma ligeira piora do sistema (1,46%). Outra acontece na execu¸c˜ao do Open Source Database Network (Fig. 4) onde h´a uma piora de 8% no caso de 48 megabytes, mesmo que tenha sido obtida melhora de 26,6% no caso de 24 megabytes.
Acreditamos que essas situa¸c˜oes se encontrem no caso em que uma grande parte das p´aginas acaba sendo comprimida sem ser usada novamente pelo sistema (pelo menos n˜ao enquanto estiver no cache comprimido).
Dessa forma, o cache comprimido acaba introduzindo mais overhead do que oferecendo vantagens para o desempenho do sistema, sendo um situa¸c˜ao pr´oxima `a caracterizada na se¸c˜ao sobre a caracteriza¸c˜ao de workloads desfavor´aveis. Acreditamos n˜ao ser poss´ıvel reverter esse quadro desfavor´avel mas apenas minimiz´a-lo.
Observemos que a presen¸ca do cache comprimido n˜ao piora o desempenho do sistema na quase totali- dade dos casos estudados e at´e melhora significativamente o desempenho em um grande n´umero deles. As melhorias chegam at´e 21,7%, 32,6% e 18,8% no tempo de compila¸c˜ao do Kernel do Linux (-j1, -j2ej4, respectivamente), at´e 31,8% na execu¸c˜ao do MUMmer e, como j´a dito acima, 26,6% no OSDB. Pol´ıticas voltadas aos casos ainda desfavor´aveis est˜ao sendo estudadas.
0 200 400 600 800 1000
18 24 30 36 42 48
Tempo de Execucao (segundos)
Memoria do Sistema (megabytes) Compilacao do Kernel do Linux (-j2)
Pentium III 1 GHz Algoritmo de Compressao: LZO
Suporte ao Page Cache Tamanho Duplo de Pagina
Cache Comprimido 2.4.18-0.24pre4 Linux Kernel Vanilla 2.4.18
Figura 2: Teste da Compila¸c˜ao do Kernel do Linux (-j2)
0 200 400 600 800 1000 1200 1400 1600 1800
18 24 30 36 42 48
Tempo de Execucao (segundos)
Memoria do Sistema (megabytes) Compilacao do Kernel do Linux (-j4)
Pentium III 1 GHz Algoritmo de Compressao: LZO
Suporte ao Page Cache Tamanho Duplo de Pagina
Cache Comprimido 2.4.18-0.24pre4 Linux Kernel Vanilla 2.4.18
Figura 3: Teste da Compila¸c˜ao do Kernel do Linux (-j4)
0 200 400 600 800 1000 1200 1400
24 48
Tempo de Execucao (segundos)
Memoria do Sistema (megabytes)
Execucao do OSDB - Open Source Database Benchmark Banco de Dados: 40MiB
Pentium III 1 GHz Algoritmo de Compressao: LZO
Suporte ao Page Cache Tamanho Duplo de Pagina
Cache Comprimido 2.4.18-0.24pre4 Linux Kernel Vanilla 2.4.18
Figura 4: Teste de Execu¸c˜ao doOpen Source Database Benchmark
0 20 40 60 80 100 120 140
330 340 345 350 355 360 380 400 420 440 460
Tempo de Execucao (segundos)
Memoria do Sistema (megabytes) Execucao do MUMmer
Pentium III 1 GHz Algoritmo de Compressao: LZO
Suporte ao Page Cache Tamanho Duplo de Pagina
Cache Comprimido 2.4.18-0.24pre4 Linux Kernel Vanilla 2.4.18
Figura 5: Teste da Execu¸c˜ao do MUMmer
4 Plano de Trabalho (Etapas Seguintes) Atividades
1 avalia¸c˜ao da implementa¸c˜ao via “micro-benchmarks”
2 inser¸c˜ao no prot´otipo dos parˆametros de adaptabilidade 3 segundo estudo do impacto docache comprimido 4 caracteriza¸c˜ao de workloads favor´aveis e desfavor´aveis 5 reda¸c˜ao de relat´orios semestrais para a Fapesp 6 reda¸c˜ao de eventuais artigos
7 reda¸c˜ao da disserta¸c˜ao 8 exame de disserta¸c˜ao
5 Cronograma (Etapas Seguintes) 2002/2003
Set Out Nov Dez Jan
1 •
2 •
3 •
4 •
5 •
6 • •
7 • • • •
8 •
Rodrigo Souza de Castro Bolsista
Prof. Dr. Alair Pereira do Lago Orientador
Referˆ encias
[1] P´agina de Patches de Con Kolivas. URL:<http://kernel.kolivas.net/>[Acessado em 06/Set/2002]. [2] P´agina de Estat´ısticas do Projeto Cache Comprimido. URL: <http://sourceforge.net/project/-
stats/?group id=13472>[Acessado em 06/Set/2002].
[3] S. F. Kaplan. Compressed Caching and Modern Virtual Memory Simulation. Tese de doutorado, University of Texas at Austin, 1999.
[4] 2.4.18 linux Kernel URL. URL:<http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.18.tar.bz2>
[Acessado em 06/Set/2002].
[5] Linux Kernel URL. URL:<http://www.kernel.org/> [Acessado em 06/Set/2002].
[6] P´agina do Projeto Cache Comprimido. URL:<http://linuxcompressed.sourceforge.net/>[Acessado em 06/Set/2002].
[7] P´agina do MUMmer. URL:<http://www.tigr.org/software/mummer/>[Acessado em 06/Set/2002]. [8] P´agina do Open Source Database Benchmark. URL: <http://osdb.sourceforge.net/> [Acessado em
06/Set/2002].
[9] P´agina de Arquivos do Open Source Database Benchmark. URL: <http://sourceforge.net/- project/showfiles.php?group id=18681>[Acessado em 06/Set/2002].
[10] P´agina de PostgreSQL. URL:<http://www.postgresql.org/>[Acessado em 06/Set/2002].
[11] P´agina dos Patches de Robert Love. URL: <http://www.tech9.net/rml/linux/>[Acessado em 06/Set/- 2002].
[12] P´agina dos Semin´arios em Sistemas de Computa¸c˜ao. URL: <http://www.ime.usp.br/~rcastro/- seminars/>[Acessado em 06/Set/2002].
[13] P. R. Wilson, S. F. Kaplan, e Y. Smaragdakis. The case for compressed caching in virtual memory systems. Em Summer 1999 USENIX Conference, p´aginas 101–116, Monterey, CA, EUA, 1999. URL:
<http://www.cs.utexas.edu/users/wilson/papers/compression.ps>[Acessado em 06/Set/2002]. [14] P´agina do Working Overloaded Linux Kernel. URL: <http://wolk.sourceforge.net/> [Acessado em
06/Set/2002].
