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.
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.
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.
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.
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.
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.
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.
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.
Veja o Material completo em: IBM developerWorks
Nenhum comentário:
Postar um comentário