[Para ver e baixar os arquivos, deve se Registrar ou Logar. ]

O ano de 2012 começou com uma novidade interessante, apesar de já esperada: Linus Torvalds lançou, no dia 4 de janeiro, a versão 3.2 do kernel Linux (código-fonte aqui). Com o codinome Saber-toothed Squirrel, “esquilo dentes-de-sabre”, esta versão enfrentou 73 dias de desenvolvimento, durante os quais recebeu 11.881 commits até alcançar 14.998.651 linhas de código distribuídas em 37.617 arquivos (confira uma tabela comparativa no The H Open Source).

Principais novidades

As novidades mais importantes do Linux 3.2 abrangem as áreas de redes TCP (otimização do algoritmo de recuperação após falhas de entrega), gerenciamento de memória (menor sobrecarga do sistema de arquivos no writeback), sistemas de arquivos Ext4 (blocos de até 1 MB) e Btrfs (melhorias na verificação de erros), controle de banda no escalonador de processos CFS e o suporte — ainda experimental — a thin provisioning e snapshots recursivos no subsistema device-mapper.

TCP Proportional Rate Reduction

O controle de transmissão realizado pelo kernel com o protocolo TCP envolve a descoberta da taxa máxima de transmissão do meio entre o emissor e o receptor. Antes do kernel 3.2, a forma de alcançar essa taxa máxima era aumentando gradativamente a taxa de emissão. Se a rede começasse a perder pacotes, a taxa era reduzida à metade e novamente aumentada pouco a pouco. A cada perda de pacote, a taxa era novamente reduzida à metade e aumentada gradativamente.

O algoritmo Proportional Rate Reduction, implementado e ativado por padrão no Linux 3.2, altera o comportamento da redução da taxa de transmissão e também o seu aumento gradativo. Segundo o desenvolvedor que propôs o patch no kernel, o resultado é uma redução entre 3% e 10% nos tempos de resposta típicos do HTTP.

Gerenciamento de memória

Quando um processo precisa acessar determinado arquivo, este é copiado do disco para a memória RAM, gerando o page cache. Após alterar o conteúdo do arquivo (gerando assim uma dirty page ou “página suja”), o kernel deve replicar essas alterações do page cache no disco, numa operação chamada writeback. Porém, o processo pode acessar diversos outros arquivos e gerar ainda mais dirty pages que necessitarão ser replicadas no disco.

O estado mais desejável para um sistema de gerenciamento de memória virtual é ter uma fração do total de páginas limpa (isto é, inalteradas em relação ao disco) e outra fração suja. Para isso, quando a proporção de páginas sujas sobre o total de páginas alcança determinado valor (que pode ser definido pelo administrador em /proc/sys/vm/dirty_ratio), o kernel tradicionalmente precisa impedir que o processo responsável suje mais páginas; neste momento, o processo passa a gastar todo o seu tempo de CPU fazendo writeback, o que gera problemas de banda de I/O e imprevisibilidade para outros processos que também precisam fazer I/O.

Um novo patch aceito no kernel 3.2 e chamado de No-I/O dirty throttling altera o mecanismo de controle de páginas sujas. Seu objetivo é manter a proporção de páginas sujas sobre o total de páginas constantemente no valor ótimo. Como efeito colateral, eventuais processos “sujões”, isto é, geradores de páginas sujas em alta velocidade, não precisarão parar sua operação para gravar as alterações direto no disco; em vez disso, simplesmente serão forçados a entrar em sleep.\\

O resultado é um sistema com respostas mais rápidas, mesmo sob intenso writeback, o que beneficia todos os tipos de usuários.

Sistemas de arquivos

Ted Ts’o, desenvolvedor principal do sistema de arquivos Ext4, implementou uma novidade no recurso chamado de bigalloc. Com isto, o alocador do Ext4 passa a ser capaz de reunir blocos menores em clusters de blocos com até 1 MB. No disco, os blocos utilizam, de fato, o tamanho do cluster. Portanto, pode-se dizer que o Ext4 agora oferece suporte a tamanhos de bloco de até 1 MB.

O resultado é uma impressionante redução no tempo de alocação de blocos e também na fragmentação de arquivos, como mostra este artigo de Ted na LWN. Porém, para utilizar tais tamanhos de blocos, é preciso usar os e2fsprogs em uma versão igual ou superior à 1.42 para formatar o sistema de arquivos informando o tamanho superior dos blocos.

O Btrfs recebeu diversas pequenas melhorias nesta versão do kernel. O desempenho do sistema de arquivos na tarefa de verificação de integridade (chamada de scrubbing) melhorou sensivelmente com o simples emprego do read-ahead nela.

Ainda na área de segurança, o Btrfs agora passa a armazenar um log das raízes do sistema de arquivos dos últimos quatro commits. Com isto, torna-se possível acessar o sistema de arquivos mesmo quando é impossível ler as raízes das árvores de seus componentes (árvores, extents, checksums e dispositivos).

O JFFS2, sistema de arquivos dedicado a dispositivos NAND Flash, ganhou suporte a compactação dos dados em disco via algoritmos LZO e ZLIB.

Escalonador de processos com controle de banda
O escalonador de processos do kernel, CFS (completely fair scheduler), sofria de generosidade excessiva: se houvesse, por exemplo, 10 cgroups dividindo a CPU, cada um usaria o máximo de tempo da CPU que conseguisse. Supunha-se que todo processo desejaria sempre toda a CPU que pudesse obter.

Em alguns casos, como provedores de computação em nuvem, é desejável limitar o máximo de banda que os cgroups podem utilizar, e é justamente esse controle de banda que o kernel 3.2 se tornou capaz de realizar.

Thin provisioning no device-mapper

O subsistema device-mapper é responsável por recursos como LVM e multipath, entre outros. Uma novidade em seu crescente quadro de recursos é o suporte a thin provisioning: a partir do kernel 3.2, passa a ser possível fornecer mais espaço de armazenamento do que se possui. Com isto, um administrador pode oferecer a cada um dos seus 20 usuários um espaço de 100 GB, mesmo que seu conjunto de discos não chegue a totalizar esses 2 TB. Evidentemente, se todos os 20 usuários resolverem consumir todos os 100 GB a que têm direito (evento surpreendentemente raro), o espaço terminará antes de alcançar esse valor. Neste momento, é hora de incluir mais discos no seu volume.

Junto ao thin provisioning, o device-mapper passa a oferecer suporte a snapshots recursivos, isto é, snapshots de snapshots de snapshots… até o limite desejado e sem desperdício de espaço.

Criptografia mais rápida

O kernel 3.2 recebeu novas implementações mais velozes (escritas em assembly) de algoritmos criptográficos na arquitetura x86-64: o blowfish ganhou novo código, o twofish tem uma nova versão paralela em 3 vias e, o SHA-1 passa a lançar mão das extensões SSSE3 de x86-64 ou AVX dos processadores Intel Sandy Bridge e AMD Bulldozer.

Nova arquitetura: Hexagon

O Linux está cada vez mais perto de rodar na sua torradeira — e nas torradas! Parece que a cada nova iteração do kernel temos uma nova arquitetura de CPU suportada. O processador da vez é o Qualcomm Hexagon, um DSP de uso geral.

Drivers de vídeo

O driver das GPUs Intel já conta com mecanismos de economia de energia há tempos. Porém, o recurso chamado de RC6 vinha desativado desde sua inclusão no kernel. Sua ativação exigia a passagem do parâmetro i915.i915_enable_rc6=1 para o kernel no carregador de boot. No Linux 3.2, o RC6 vem ativado por padrão para todas as GPUs Intel — exceto aquelas dos processadores Sandy Bridge, pois apresentaram alguns problemas após a inclusão do código.

Já no campo da Nvidia, o novo kernel oferece suporte às GPUs com núcleo NVCF, isto é, GeForce GTX 550 Ti e 560M. Além disso, o driver Nouveau passa a utilizar as funções do firmware das GPUs NVC1, NVC8 e NVCF para aceleração.

Drivers wi-fi

Os diversos usuários de chips wi-fi Broadcom veem um fenômeno interessante há meses: a briga entre dois drivers diferentes — brcmsmac e b43 — para um mesmo conjunto de dispositivos. No kernel 3.2, o driver brcmsmac conseguiu deixar a árvore staging e ser integrado ao ramo principal do código do kernel.

Fenômeno semelhante ocorreu com o driver Ath6kl, para chips Atheros AR6003, que foi promovido à área principal.

Futuro
O kernel 3.3 deve ser lançado em meados de março, trazendo de volta diversos drivers para Android na árvore staging. Esses drivers haviam sido expurgados da mesma staging pelos desenvolvedores em 2010 no kernel 2.6.33, mas um novo esforço — viva! — visa a trazê-los de volta.

No campo das redes, é provável que o kernel 3.3 traga um recurso para substituir o bonding, chamado ethernet teaming device. Além disso, o combate ao chamado buffer bloat (um exagero dos buffers de rede em hardware e software) deve ser intensificado na próxima versão do kernel com o recurso de byte queue limiting.

É possível também que vejamos a inclusão do Open vSwitch, um switch virtual usado no Citrix XenServer 6.

O Btrfs ainda precisará de retoques antes de se tornar estável — desejo declarado pela Oracle, desenvolvedora principal deste sistema de arquivos — tais como um fsck e o suporte a RAID 5 e 6.

Fonte: IBM