As novidades do Linux 2.6.38
No último dia do Pi (14 de março, ou 3/14 na notação usada nos EUA) foi lançada a versão 2.6.38 do kernel Linux. Com apenas 69 dias de desenvolvimento, este foi o kernel liberado no menor intervalo desde a versão 2.6.20 (pronta em 66 dias e lançada em fevereiro de 2007). Contudo, seu volume de alteração não é diferente daqueles das versões anteriores — ou seja, o pessoal do kernel fez mais em menos tempo. O resultado foi um kernel com poucas — porém ótimas — novidades.
Mantendo o codinome Flesh-Eating Bats With Fangs inaugurado na versão [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/as_novidades_do_kernel_2_6_3611?lang=pt_br]2.6.36[/url] e também usado no Linux [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/as_novidades_do_kernel_2_6_3611?lang=pt_br]2.6.37[/url], o kernel 2.6.38 traz algumas novidades muito interessantes.
[b]Já anunciado: sistema perceptivelmente mais rápido[/b]
Conforme anunciado [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/tags/kernel?lang=pt_br]num post anterior neste blog[/url], o patch maravilha que melhora significativamente a percepção de velocidade — isto é, reduz a latência dos processos interativos — finalmente foi incluído no Linux. Desenvolvido e apresentado à lista do kernel em outubro do ano passado, o patch não amadureceu a tempo para ser incluído no Linux 2.6.37, e agora estreia na versão atual.
O nome oficial do novo recurso é “agrupamento automático de processos”, o que não dá uma ideia muito precisa de seus fantásticos resultados. Quando ativo, o agrupamento automático de processos faz com que processos sejam agrupados de acordo com a sessão que os iniciou e ocupem uma única “fatia” do tempo de processamento. Assim, os processos de um grupo não conseguem interferir na latência dos processos de outro grupo, pois cada grupo tem seu tempo definido para ocupar o processador. O efeito é que aplicativos interativos, como navegadores, clientes de e-mail e processadores de texto não demonstram lentidão em sistemas que estejam ocupadíssimos com grandes compilações, por exemplo.
[quote][i]Resumindo novamente: o desktop tem resposta mais rápida em sistemas sob carga intensa.[/i][/quote]
Para mais detalhes e um breve histórico deste recurso, [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/tags/kernel?lang=pt_br]confira o post anterior aqui no blog[/url], os links que ele aponta e também [url=http://kernelnewbies.org/Linux_2_6_38#head-bd31172f390514636ace788ff8287aa620e5ea3f]a explicação muito didática do Kernel Newbies[/url], além do [url=https://lwn.net/Articles/418884/]artigo aprofundado no LWN[/url].
Outra novidade já anunciada afeta a velocidade (positivamente, claro!) do acesso a disco. É o pathname lookup (consulta de caminhos) em cache. Basicamente, o mecanismo de RCU (read-copy-update) usado para consultar caminhos de arquivos em cache foi melhorado tanto que, segundo relato do próprio Linus Torvalds, [url=http://kernelnewbies.org/Linux_2_6_38#head-bd31172f390514636ace788ff8287aa620e5ea3f]um find . -size em seu diretório home ficou 35% mais rápido[/url]. E o melhor: quanto maior o número de threads acessando o disco em paralelo, maior é o ganho de desempenho percebido (64 git diffs paralelos têm desempenho 26 vezes melhor)!
[b]GPU![/b]
No campo da AMD, o kernel 2.6.38 traz suporte às GPUs Fusion em seu driver KMS (kernel mode-setting), além de incluir as GPUs 62xx e 68xx entre os modelos suportados (todas com aceleração 3D, diga-se de passagem).
Já na concorrente Nvidia, o driver Nouveau agora oferece suporte completo (inclusive 3D — mas isto depende dos demais componentes gráficos de software) aos chips da família Fermi.
Por fim, na área da Intel, foi melhorado o suporte aos modos de economia de energia nas GPUs embutidas em chips da família Sandy Bridge. Além disso, as alterações permitem também que essas GPUs alterem sua frequência de operação numa espécie de “overclock autônomo” — suportado pelo fabricante, evidentemente — que melhora significativamente o desempenho da GPU.
[b]Btrfs compactado[/b]
O próximo-sistema-de-arquivos-padrão do Linux, o impronunciável [url=https://btrfs.wiki.kernel.org/index.php/Main_Page]btrfs[/url], já tinha uma opção de compactação transparente de arquivos. No entanto, a única opção de algoritmo era a zlib, que oferece boa compactação mas exige muito processamento — e portanto perde velocidade. No Linux 2.6.38, o btrfs ganha também a opção do algoritmo LZO, que [url=https://lwn.net/Articles/416644/]compacta menos, mas oferece desempenho significativamente melhor que a zlib[/url].
[b]Hugepages transparentes[/b]
Quando um processo aloca memória, ele pode optar por páginas de memória de tamanho normal (4 KiB em x86 e x86-64) ou por huge pages (páginas enormes) (2 MiB ou 4 MiB em ambas arquiteturas). Com o recurso de huge pages, o sistema consegue manter maiores porções da memória indexadas no cache de endereços de memória (chamado de TLB).
Até a versão 2.6.37, o kernel Linux exigia certos procedimentos do administrador de sistemas (montagem do sistema de arquivos virtual hugetlbfs) e do programador (uso de funções shmget e mmap em vez de malloc & cia.) para que as “páginas enormes” fossem empregadas. A partir de agora, o kernel é capaz de decidir pelo uso de huge pages no momento da alocação pelo aplicativo, o que promete melhorar significativamente o desempenho de todo programa que faz uso de grandes porções de memória — melhor exemplo: virtualização.
No momento, o suporte a hugepages transparentes só funciona com páginas anônimas de memória. Nas próximas versões do kernel, espera-se que outros tipos de páginas de memória também recebam suporte, de forma a beneficiar o sistema de arquivos tmpfs e muito mais.
[b]
Ext3 e XFS em discos SSD[/b]
Um único recurso promete melhorar significativamente o desempenho de sistemas de arquivos Ext3 e XFS em discos de estado sólido (SSD): batched discard. Com ele, esses sistemas de arquivos podem marcar certos blocos como descartados e informar esse fato ao dispositivo de blocos (o disco SSD, no caso) caso os blocos permaneçam vazios durante certo período por meio do comando TRIM. O batched discard já estava presente no Ext4 desde o kernel 2.6.37.
Ainda nos sistemas de arquivos, o SquashFS, que já havia ganho a capacidade de compactar dados com o poderosíssimo LZMA, agora também pode trabalhar com seu irmão XZ. Somado à remoção da BKL (Big Kernel Lock) do sistema de arquivos UDF, os Live DVDs baseados nesta versão do kernel certamente terão grandes ganhos de velocidade e capacidade.s
[b]Pass-through na rede[/b]
O driver macvlan ganhou um modo de pass-through que deve melhorar o desempenho de rede de máquinas virtuais que o utilizam, pois permite ao sistema hóspede comunicar-se diretamente com o hardware de rede subjacente — inclusive para criar VLANs e alterar o endereço MAC, por exemplo.
[b]Promoção de código[/b]
O caminho natural de códigos residentes na árvore staging é que amadureçam e sejam promovidos à árvore principal do kernel. Foi isto que ocorreu com o código de rede B.A.T.M.A.N — que implementa redes mesh.
Outros códigos promovidos foram o driver b43 para redes sem fio 802.11n — antes marcado como “quebrado” — e o suporte a chips wi-fi Ralink RT309x (PCI/PCIe) e RT307x (USB), antes externo e agora parte integrante dos drivers rt2800pci e rt2800usb no kernel.
[b]
Dom0 do Xen quase pronto[/b]
O suporte preliminar a Dom0 do Xen foi inaugurado no Linux 2.6.37. No 2.6.38, algumas novas funcionalidades foram acrescentadas, mas ainda faltam os drivers do back-end, sem os quais o Dom0 Linux fica relativamente inútil. Esses drivers são esperados — juntamente com o suporte pleno a Dom0 no Xen — no kernel 2.6.39 ou 2.6.40.
[b]Futuro[/b]
O kernel Linux 2.6.39 deve ser lançado no final de maio ou início de junho, e a única previsão significativa é que o suporte a dom0 do Xen seja finalizado (com otimismo) ou ao menos veja grandes avanços (mais realista).
Até mais!
--------------------
Transcrito [url=http://aurelianomartins.wordpress.com/2011/03/21/as-novidades-do-linux-2-6-38/]daqui[/url].
[b]Fiquem com Deus.[/b]
Mantendo o codinome Flesh-Eating Bats With Fangs inaugurado na versão [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/as_novidades_do_kernel_2_6_3611?lang=pt_br]2.6.36[/url] e também usado no Linux [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/as_novidades_do_kernel_2_6_3611?lang=pt_br]2.6.37[/url], o kernel 2.6.38 traz algumas novidades muito interessantes.
[b]Já anunciado: sistema perceptivelmente mais rápido[/b]
Conforme anunciado [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/tags/kernel?lang=pt_br]num post anterior neste blog[/url], o patch maravilha que melhora significativamente a percepção de velocidade — isto é, reduz a latência dos processos interativos — finalmente foi incluído no Linux. Desenvolvido e apresentado à lista do kernel em outubro do ano passado, o patch não amadureceu a tempo para ser incluído no Linux 2.6.37, e agora estreia na versão atual.
O nome oficial do novo recurso é “agrupamento automático de processos”, o que não dá uma ideia muito precisa de seus fantásticos resultados. Quando ativo, o agrupamento automático de processos faz com que processos sejam agrupados de acordo com a sessão que os iniciou e ocupem uma única “fatia” do tempo de processamento. Assim, os processos de um grupo não conseguem interferir na latência dos processos de outro grupo, pois cada grupo tem seu tempo definido para ocupar o processador. O efeito é que aplicativos interativos, como navegadores, clientes de e-mail e processadores de texto não demonstram lentidão em sistemas que estejam ocupadíssimos com grandes compilações, por exemplo.
[quote][i]Resumindo novamente: o desktop tem resposta mais rápida em sistemas sob carga intensa.[/i][/quote]
Para mais detalhes e um breve histórico deste recurso, [url=https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/tags/kernel?lang=pt_br]confira o post anterior aqui no blog[/url], os links que ele aponta e também [url=http://kernelnewbies.org/Linux_2_6_38#head-bd31172f390514636ace788ff8287aa620e5ea3f]a explicação muito didática do Kernel Newbies[/url], além do [url=https://lwn.net/Articles/418884/]artigo aprofundado no LWN[/url].
Outra novidade já anunciada afeta a velocidade (positivamente, claro!) do acesso a disco. É o pathname lookup (consulta de caminhos) em cache. Basicamente, o mecanismo de RCU (read-copy-update) usado para consultar caminhos de arquivos em cache foi melhorado tanto que, segundo relato do próprio Linus Torvalds, [url=http://kernelnewbies.org/Linux_2_6_38#head-bd31172f390514636ace788ff8287aa620e5ea3f]um find . -size em seu diretório home ficou 35% mais rápido[/url]. E o melhor: quanto maior o número de threads acessando o disco em paralelo, maior é o ganho de desempenho percebido (64 git diffs paralelos têm desempenho 26 vezes melhor)!
[b]GPU![/b]
No campo da AMD, o kernel 2.6.38 traz suporte às GPUs Fusion em seu driver KMS (kernel mode-setting), além de incluir as GPUs 62xx e 68xx entre os modelos suportados (todas com aceleração 3D, diga-se de passagem).
Já na concorrente Nvidia, o driver Nouveau agora oferece suporte completo (inclusive 3D — mas isto depende dos demais componentes gráficos de software) aos chips da família Fermi.
Por fim, na área da Intel, foi melhorado o suporte aos modos de economia de energia nas GPUs embutidas em chips da família Sandy Bridge. Além disso, as alterações permitem também que essas GPUs alterem sua frequência de operação numa espécie de “overclock autônomo” — suportado pelo fabricante, evidentemente — que melhora significativamente o desempenho da GPU.
[b]Btrfs compactado[/b]
O próximo-sistema-de-arquivos-padrão do Linux, o impronunciável [url=https://btrfs.wiki.kernel.org/index.php/Main_Page]btrfs[/url], já tinha uma opção de compactação transparente de arquivos. No entanto, a única opção de algoritmo era a zlib, que oferece boa compactação mas exige muito processamento — e portanto perde velocidade. No Linux 2.6.38, o btrfs ganha também a opção do algoritmo LZO, que [url=https://lwn.net/Articles/416644/]compacta menos, mas oferece desempenho significativamente melhor que a zlib[/url].
[b]Hugepages transparentes[/b]
Quando um processo aloca memória, ele pode optar por páginas de memória de tamanho normal (4 KiB em x86 e x86-64) ou por huge pages (páginas enormes) (2 MiB ou 4 MiB em ambas arquiteturas). Com o recurso de huge pages, o sistema consegue manter maiores porções da memória indexadas no cache de endereços de memória (chamado de TLB).
Até a versão 2.6.37, o kernel Linux exigia certos procedimentos do administrador de sistemas (montagem do sistema de arquivos virtual hugetlbfs) e do programador (uso de funções shmget e mmap em vez de malloc & cia.) para que as “páginas enormes” fossem empregadas. A partir de agora, o kernel é capaz de decidir pelo uso de huge pages no momento da alocação pelo aplicativo, o que promete melhorar significativamente o desempenho de todo programa que faz uso de grandes porções de memória — melhor exemplo: virtualização.
No momento, o suporte a hugepages transparentes só funciona com páginas anônimas de memória. Nas próximas versões do kernel, espera-se que outros tipos de páginas de memória também recebam suporte, de forma a beneficiar o sistema de arquivos tmpfs e muito mais.
[b]
Ext3 e XFS em discos SSD[/b]
Um único recurso promete melhorar significativamente o desempenho de sistemas de arquivos Ext3 e XFS em discos de estado sólido (SSD): batched discard. Com ele, esses sistemas de arquivos podem marcar certos blocos como descartados e informar esse fato ao dispositivo de blocos (o disco SSD, no caso) caso os blocos permaneçam vazios durante certo período por meio do comando TRIM. O batched discard já estava presente no Ext4 desde o kernel 2.6.37.
Ainda nos sistemas de arquivos, o SquashFS, que já havia ganho a capacidade de compactar dados com o poderosíssimo LZMA, agora também pode trabalhar com seu irmão XZ. Somado à remoção da BKL (Big Kernel Lock) do sistema de arquivos UDF, os Live DVDs baseados nesta versão do kernel certamente terão grandes ganhos de velocidade e capacidade.s
[b]Pass-through na rede[/b]
O driver macvlan ganhou um modo de pass-through que deve melhorar o desempenho de rede de máquinas virtuais que o utilizam, pois permite ao sistema hóspede comunicar-se diretamente com o hardware de rede subjacente — inclusive para criar VLANs e alterar o endereço MAC, por exemplo.
[b]Promoção de código[/b]
O caminho natural de códigos residentes na árvore staging é que amadureçam e sejam promovidos à árvore principal do kernel. Foi isto que ocorreu com o código de rede B.A.T.M.A.N — que implementa redes mesh.
Outros códigos promovidos foram o driver b43 para redes sem fio 802.11n — antes marcado como “quebrado” — e o suporte a chips wi-fi Ralink RT309x (PCI/PCIe) e RT307x (USB), antes externo e agora parte integrante dos drivers rt2800pci e rt2800usb no kernel.
[b]
Dom0 do Xen quase pronto[/b]
O suporte preliminar a Dom0 do Xen foi inaugurado no Linux 2.6.37. No 2.6.38, algumas novas funcionalidades foram acrescentadas, mas ainda faltam os drivers do back-end, sem os quais o Dom0 Linux fica relativamente inútil. Esses drivers são esperados — juntamente com o suporte pleno a Dom0 no Xen — no kernel 2.6.39 ou 2.6.40.
[b]Futuro[/b]
O kernel Linux 2.6.39 deve ser lançado no final de maio ou início de junho, e a única previsão significativa é que o suporte a dom0 do Xen seja finalizado (com otimismo) ou ao menos veja grandes avanços (mais realista).
Até mais!
--------------------
Transcrito [url=http://aurelianomartins.wordpress.com/2011/03/21/as-novidades-do-linux-2-6-38/]daqui[/url].
[b]Fiquem com Deus.[/b]
Entre ou Registre-se para fazer um comentário.