Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Novidades do kernel Linux 2.6.38

Enviado por Pablo Hess (pabloΘhess·net·br):

“O kernel 2.6.38 foi lançado dia 14 de março, mas pouca gente atentou ao fato de que, das últimas versões, esta foi a que trouxe novidades mais perceptíveis no uso cotidiano do kernel do pinguim.

Publiquei no meu blog no IBM developerWorks uma análise de todas as principais novidades desta versão mais recente do kernel e quais benefícios elas trazem.

Por exemplo, você sabia que um simples “find”, que usa uma única thread, ficou 35% mais rápido (dados de Linus Torvalds)? E que acessos concorrentes a caminhos de diretório ficaram dezenas de vezes mais velozes?

Além disso, há avanços no escalonador de processos do kernel: se você estiver compilando um aplicativo com “make -j 20″ num terminal e tentar navegar na Internet no Firefox, as páginas web vão passar pelo navegador como se o processador fosse todo dele. Experimente isso nas versões anteriores do kernel!

O post ainda lista outros avanços na área de suporte a chips gráficos, no promissor sistema de arquivos btrfs, I/O de rede em máquinas virtuais etc.” [referência: ]


• Publicado por Augusto Campos em 2011-03-21

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 9:10 am

    Pela primeira vez, o wireless é tão bom quanto o do Windows 7 nos meus netbooks, já posso chutar o seven, porque antes conectava depois de quase 2min. e em menos de 5 já se desconectava sozinho e pedia novamente a senha, agora “tá só o filé”.

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 9:13 am

    Alguém poderia explicar por que o kernel tem essa numeração 2.6.38? Sairá algum dia um kernel 3?

    Luciano (usuário não registrado) em 21/03/2011 às 9:17 am

    Como consegui até hoje viver sem isso? Sempre compilo coisas com “make -j 20″ e uso o navegador. Meus dias serão melhores, é incrível querido.

    @Luciano

    Esse foi só um exemplo extremos de aumento da responsividade sob altas cargas de trabalho no sistema.

    A melhora é perceptiva em todas as tarefas.

    Bremm (usuário não registrado) em 21/03/2011 às 10:33 am

    Notei que o ‘catfish’ havia ficado sensivelmente mais rápido. Essa do ‘find’ acelerado eu desconhecia! =D

    Sugestão para quem está usando o 2.6.38: leia sobre o projeto ulatencyd.

    Junin (usuário não registrado) em 21/03/2011 às 10:35 am

    Nunca deixo de ler os post sobre as novidades do kernel.
    Com certeza deve ser o mais completo no idioma tupiniquim :o)

    Marcelo Gondim (usuário não registrado) em 21/03/2011 às 10:47 am

    Um dos meus servidores ficou extremamente mais leve. Percebi isso olhando a carga do sistema. Mas para tráfegos altos não ficou bom não ou tem alguma mágica que desconheço. No gateway aqui da empresa cujo tráfego é de em média 130Mbps com link total de 200Mbps tive o seguinte problema: Uso muito alto de processamento nos ksoftirqs dava pra ver claramente no top. Dava 80 à 90% de uso me gerando perdas de pacotes e lentidão. Voltei para o kernel 2.6.32 que pelo menos isso não acontecia. Bem vou aguardar algum patch pra ver se isso melhora. :)

    Marcelo Gondim, a única diferença que me lembro de ter visto foi em dispositivos “multiqueue”. É o seu caso? Se for, então o load average talvez tenha aumentado porque o kernel agora decide a fila de rede que vai usar de acordo com a CPU encarregada daquela fila (recurso XPS, irmão do RPS). Se não houver um mapeamento legal, ou (imagino) se o seu dispositivo tiver muito mais filas do que CPUs, o load average pode mesmo aumentar.

    Mas seria (teoricamente) por um bom motivo: aumento significativo do throughput de rede.

    No seu caso, como o resultado foi o oposto a esse, é bom associar cada fila a uma CPU, por meio do arquivo ‘/sys/class/net/eth/queues/tx-/xps_cpus’. Talvez surta o efeito positivo desejado.

    Junin, muito obrigado! Eu gosto muito de escrevê-los. E se você gosta do assunto, os links no final do artigo são imperdíveis.

    Lx (usuário não registrado) em 21/03/2011 às 11:50 am

    @Carlos Felipe,

    Quando todas as alterações planejadas no 2.6 tiverem sido feitas, uma versão 2.8 surgirá. Terminando ela surgirá a 3.0. As versões com o segundo valor ímpar são instáveis e em desenvolvimento. Ex: 2.1, 2.3, 2.5…. Estáveis segundo valor par. Ex: 2.0, 2.2, 2.4, 2.6.

    @Lx,

    Este esquema de numeração valeu até o 2.5/2.6, mas é cada vez mais um resquício do passado. Do jeito que a coisa está indo, os desenvolvedores não precisam mais abrir uma nova árvore de desenvolvimento (a 2.7, no caso) pra alterar grandes trechos do código. Os caras já conseguem trocar o pneu com o caminhão andando, e **sem quebrar nada**.

    @Carlos Felipe,

    Já houve no passado algum início de discussão sobre alterações no esquema de numeração do kernel. Chegaram a propor números como 2011-02 (segundo kernel lançado em 2011), ou 2.6.38-02-2011, ou 2011-38 (já que o 2.6 atualmente está sempre presente). Porém, isso quebraria vários programas que precisam consultar a versão do kernel — por exemplo, à espera de “2″, ou “2.6″, ou “2.6.25-ou-maior”. No final, decidiram manter o esquema antigo.

    Será que chegaremos a ver um terceiro dígito no terceiro número? :-D

    Marce Gondim (usuário não registrado) em 21/03/2011 às 1:01 pm

    @phess,

    Opa Pablo rapaz eu usei a config do kernel 2.6.32 como base na configuração do 2.6.38. Tem alguma sugestão do que talvez possa ser feito para a melhora de performance nesse problema? Porque pode ter ficado alguma option desmarcada e que seja necessária. :)

    Estou lendo aqui sobre o XPS e o RPS. Valeu pela dica e parabens pelo post :)

    Maurício (usuário não registrado) em 21/03/2011 às 2:25 pm

    Pelo que sei, o próprio Linus já disse que nunca haverá a versão 3.0 do kernel.

    O número 2 seguido de outros números será mantido indefinidamente.

    aaaaaaaaa (usuário não registrado) em 21/03/2011 às 2:30 pm

    Pra sair da versão 2.2 até a 2.6 já demorou pacas… imagina pra ir pra 2.8… deve demorar bastante… depois capaz de vir a 2.10… se um dia vier a versão 3.0, talvez nossos netos estejam mexendo com isso…

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 5:05 pm

    @Maurício: “Pelo que sei, o próprio Linus já disse que nunca haverá a versão 3.0 do kernel.”

    E esta?
    “640K sempre serão suficientes (Bill Gaytes, 1981)”

    Ícaro (usuário não registrado) em 21/03/2011 às 5:36 pm

    Nesse caso é diferente, Carlos Felipe.

    O kernel pode ir até 2.6.999999999999999999999999999999999… mas vai ter uma melhora incrível, será outro kernel, mas apenas continua versão 2.6 ;)

    O GNOME poderia lançar a versão 2.32.1, mas apenas mudou para o número para 3…

    O que muda só é o número, isso é o mínimo.

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 6:02 pm

    Se o kernel será sempre 2.6.38, poderian até remover o 2, kernel 6.38 :P

    Mauricio (usuário não registrado) em 21/03/2011 às 6:42 pm

    E esta?
    “640K sempre serão suficientes (Bill Gaytes, 1981)”

    Pois é, mas no caso do Kernel, ou de qualquer programa, os padrões numéricos são dados pelo próprio desenvolvedor.

    Claro que as melhorias no kernel são significativas em cada versão, mas não sei porque não existe essa decisão de trocar de versão do kernel (2.x para 3.x). Mas é uma decisão do próprio Linus. Veja:

    http://www.daniweb.com/hardware-and-software/linux-and-unix/linux-servers-and-apache/news/218605

    Marcelo Gondim (usuário não registrado) em 21/03/2011 às 6:52 pm

    É realmente existe algum problema mesmo com esse XPS. Aqui observando com:

    watch -n0 cat /proc/interrupts

    Eu percebo que as interfaces de rede estão balanceando em todas as CPUs mas acontecem umas travadas, lentidão na digitação da console, perda de pacotes e no “top” acusa ksoftirq dando 90% de uso de processamento e load de 1.20. Já com o kernel 2.6.32 nada disso ocorre, o balanceamento ocorre normal entre as CPUs, não existe o travamento e nem perda de pacotes. O load fica em 0.05 em média.

    O equipamento é um Intel Quad Core com interfaces Intel Gigabit. Existe algo realmente errado por aí. Usei o .config do kernel 2.6.32 como base para configurar o 2.6.38.

    Vou aguardar mais e ver como vai ficar. :)

    Renan (usuário não registrado) em 21/03/2011 às 6:59 pm

    ” mas não sei porque não existe essa decisão de trocar de versão do kernel (2.x para 3.x)”

    Imagino que isso só ocorreria se houvesse uma grande mudança na arquitetura do kernel.

    Guto (usuário não registrado) em 21/03/2011 às 7:08 pm

    Uma coisa que não gosto no comportamento do Linux é quando estou por exemplo baixando uma atualização da distribuição que esta usando toda a velocidade do meu link da internet, fica impraticável qualquer navegação ou outro serviço que necessite da internet. No Windows parece que ele distribui o link melhor entre as aplicações coisa que o Linux não faz. Isso tudo no mesmo desktop.

    Maurício (usuário não registrado) em 21/03/2011 às 7:11 pm

    Guto, não é isso que acontece aqui em casa.

    Talvez o problema seja com a distro que vc está usando.

    Bremm (usuário não registrado) em 21/03/2011 às 7:31 pm

    @ Guto

    Isso acontece quando a conexão de saída (uplink/upstream) fica saturada.

    http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

    Um outro problema pode ser o valor do MTU da interface de rede.

    http://www.dslreports.com/faq/695

    Outra novidade deste kernel: mais suporte para placas USB de TV Digital. Especificamente, já funciona a placa PlayTV USB Hybrid (mas sem suporte para hotswap, ainda).

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 8:32 pm

    Estes pen-drives que rodam TV digital já pegam nativamente no Linux?

    Carlos Felipe (usuário não registrado) em 21/03/2011 às 8:59 pm

    Pra quem não quiser compilar, existe o projeto Ubuntu Mainline kernel que disponibliza os DEB já compilados

    http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.38-natty/

    André Machado (usuário não registrado) em 21/03/2011 às 10:59 pm

    Sobre a discussão de quando haverá um kernel 3.0, leiam esse artigo de 2002:

    “A recent lkml thread explored an interesting tangent when Jeff Garzik asked about what was to follow the 2.5 development kernel, “is it definitely to be named 2.6? Maybe it’s just my impression from development speed, but it felt more like a 3.0 to me :)”. Linux creator Linus Torvalds first suggested that there was no reason to skip from 2.5 to 3.0, qualifying it with, “But hey, it’s just a number. I don’t feel that strongly either way.”"

    http://kerneltrap.org/node/436

    André Machado (usuário não registrado) em 21/03/2011 às 11:02 pm

    Essa outra página aqui explica a questão melhor: http://www.daniweb.com/hardware-and-software/linux-and-unix/linux-servers-and-apache/news/218605

    “The first hints are given when he responds to a question concerning why the 2.6 kernel has been around for so long, and explains his reasoning as to why a multi-year development cycle doesn’t work concluding that the 2.6 base kernel is in such good shape that there is no pressing reason to go back to the old ‘everything changes’ development model. Torvalds adds “that means that we’ll keep with the 2.6.x codebase, and just incrementally improve on it.”

    When questioned further, specifically about when we can expect to see the version 3.0 kernel, Torvalds states quite categorically that “we really don’t expect to need to go to a 3.0.x version at all”

    Lindrix (usuário não registrado) em 25/03/2011 às 8:19 pm

    @José Antonio Meira da Rocha,

    Pra tanto que já existe uma analise e procedimento inicial de configuração do adaptador:

    http://meiradarocha.jor.br/news/2011/03/17/placa-pixelview-playtv-hybrid-no-linux-ubuntu/comment-page-1/#comment-4145

    A tv rola no TVtime, mas um tvtime-scanner e uma mexida no arquivo de configuração dele serão necessários antes. Ainda sem som.

Este post é antigo (2011-03-21) e foi arquivado. O envio de novos comentários a este post já expirou.