Edgy Eft não terá mais kernels p/ k7 e 686!

[galactus]

KurtKraut
10/09/2006

"Além dos cassetes ( http://pt.wikipedia.org/wiki/Cassete ), os k7 também serão coisa do passado. Quem tem acompanhado o desenvolvimento do Ubuntu Edgy Eft e utilizava um kernel específico para as arquiteturas k7, 686 ou amd64 já deve ter notado a presença de um linux-image-generic no lugar de seu kernel habitual.

Pois bem, em recentes benchmarks ( https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060814/82176505/attachment-0001.eml ) (bem simples - https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019983.html - diga-se de passagem) notaram que não havia um considerável ganho de desempenho entre um kernel 386 e outro 686 que justificasse o custo operacional de manter o kernel especial. O mesmo se verificou entre as variantes amd64-generic e amd64-xeon.

Um único teste foi realizado comparando o kernel compilado para 386 e para k7. As diferenças foram maiores do que as encontradas entre 386/686. Mas ainda assim não acharam justificável a permanência do linux-image-k7.

Sendo assim, os pacotes linux-image-generic ( http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.17/linux-source-2.6.17_2.6.17-7.19/changelog ) nos desktops e o linux-image-server nos servidores irão atender os processadores das famílias 686 e k7 sem otimizações específicas para os mesmos. As variantes 64 bits como amd64-k8 ou amd64-xeon deixarão de existir e estes processadores serão atendidos por um kernel de fato compilado para 64 bits mas com o nome linux-image-generic por uma questão de simplificação. Resta aos adictos pelos kernels especiais a tarefa de compilá-los por conta própria.

Apesar de eu concordar que mais testes ( https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/020007.html ) são necessários , essas alterações não devem causar decréssimo notável de desempenho por parte do usuário por mais que soe de início. Portanto, nada de alardes. Mas fica o convite a todos a fazerem mais benchmarks ( http://en.wikipedia.org/wiki/Benchmark_(computing) ) que tragam números que talvez demonstrem que essa decisão não deveria ter sido tomada, porém, até agora nenhum surgiu nesse sentido.

O Edgy tem sim ganhos de performance, vindo de reorganizações do processo de boot ( https://features.launchpad.net/distros/ubuntu/+spec/replacement-init ), de desligamento ( https://features.launchpad.net/distros/ubuntu/+spec/teardown ) e até do LiveCD ( https://features.launchpad.net/distros/ubuntu/+spec/optimized-live-cd-layout-for-faster-boot ). Além, é claro, das melhorias costumeiras das novas versões de todos os pacotes. O que deve vir a tona para próximas versões são as discussões sobre medidas mais intrusivas na melhoria de performance como preload ( http://sourceforge.net/projects/preload ) ou o prelink ( http://ubuntuforums.org/showthread.php?t=74197 ).

O preload analisa os hábitos do usuário e a partir desta análise prevê quais aplicações serão abertas em seguida no sistema e já as carrega juntamente com suas dependências para acelerar a abertura mediante a solicitação do usuário.

Já o prelink faz a ligações das aplicações com suas bibliotecas e armazena estas informações que usualmente são criadas cada vez que o programa é aberto. Como haverá uma espécie de ‘cache’ para estas ligações, o processo de abertura de programas que requerem muitas bibliotecas deverá ser acelerado. Há obviamente um custo: a instalação de programas via APT passa a ser mais demorada e a interrupção do processo de prelinking pode causar a quebra do sistema ou aplicação. O Fedora e o SuSE já usam prelink por padrão em algumas aplicações específicas."

Fonte: Planeta Ubuntu Brasil - http://planeta.ubuntubrasil.org/post/1008

[Screwball]

Tenho um Athlon64 e não gostei nem um pouco da novidade...
Além de não haver um kernel 32 bits para o K8 (existia apenas o 64 bits) ainda retiram o K7.

Claro, podemos compilar o próprio kernel, mas é uma mão de obra, e envolve recompilar outras partes do sistema, como alguns módulos, etc; além de ser uma potencial fonte de incompatibilidades com outros pacotes instalados via apt-get, de não ter atualizações automáticas para o kernel e módulos...

E por aí vai.
Enfim, uma grande chateação.

Espero que voltem atras nessa decisão. 

[rodrigo666]

Tenho um Athlon64 e não gostei nem um pouco da novidade...
Além de não haver um kernel 32 bits para o K8 (existia apenas o 64 bits) ainda retiram o K7.

Claro, podemos compilar o próprio kernel, mas é uma mão de obra, e envolve recompilar outras partes do sistema, como alguns módulos, etc; além de ser uma potencial fonte de incompatibilidades com outros pacotes instalados via apt-get, de não ter atualizações automáticas para o kernel e módulos...

E por aí vai.
Enfim, uma grande chateação.

Espero que voltem atras nessa decisão. 

Certo, mas pelo o que se lê na notícia, de acordo com os tais benchmarks, não tem grande diferença em usar os tais kernel otimizados.

[cobra_floripa]

Uma pergunta de iniciante,

E o modulo smp (HT para p4)? será possível instala-lo?

[KurtKraut]

E o modulo smp (HT para p4)? será possível instala-lo?

Sim. Em benchmarks preliminares, até então o que foi constatado é que a presença do SMP não prejudica o desempenho do kernel em processadores single core. A tendência é que todos os kernels venham com suporte a SMP, incluindo o LiveCD, tendo um suporte a essa tecnologia 'out of the box' sem prejudicar os processadores mais comuns de hoje.

[Intruder_A6]

Isto me deixou muito chateado, pois uma das coisas que eu gostava muito na distribuição era de não precisar recompilar o kernel para ter o Linux razoavelmente otimizado para a minha máquina. Mas agora serei obrigado a compilar o kernel ( coisa que já tinha parado de fazer depois de abandonar o Conectiva Linux ), e fico imaginando se não terei problemas com o driver proprietário da nVidia

E ai, vocês sabem se é possível compilar o kernel mudando o nome da versão ( para diferenciar do original ), e mesmo assim ter suporte a aceleração 3D pelo driver da nVidia

[greylica]

Eu vejo da seguinte maneira, na realidade quase tudo o que temos hoje é compilado para I686 ( PII, K6II e ou superiores, (Pentium I e K5/K6 I é I386 Puro ), e na maioria dos casos nós não usamos mais que 4GB de RAM então as extensões EMt64T para Xeon I e II normalmente são poucos os que as usam. Alguns softwares compilados pelo SCons utilizam as funções do processador mesmo sem precisar de um kernel específico, e para as tarefas dia a dia isso não é uma exigência suprema. O SMP é extremamente necessário, visto que temos Core 2 Quad chegando por aí, mas apesar de ter SSE 1 ,2 e 3 e instruções mixas de 64 bits, em geral que usa mesmo isso são os programas compilados, como MySQL, Blender, Pov Ray, e etc. As otimizações á nível de kernel ajudam pouco e além de tudo cortam uma função de economia de energia C1/S2 que faz os processadores ficarem mais frios em plataforma Linux, coisa que não teríamos se utilizássemos todas as porções do processador para tarefas mundanas.
Minha única preoupação são algumas máquina híbridas de Xeon , Athlon MP e alguns socketes 754 com 4 GB de RAm e que podem não rodar direito aplicações de 32 bits com mais de 4Gb de RAM por que o kernel não vai usar o Page Adress Extension do processador. E O kernel de 64 bits ainda está dando pau com aplicações mistas de 32 bits por causa dos drivers.
Como tudo isso é apenas uma fase de transição de tecnologias, a bagunça está feita de tal maneira que logo logo vai acabar a festa e teremos 32=32 e 64=64 e cada software com sua otimizações para plataformas específicas.

Resumindo = Único problema é o PAE em 32 bits.

Eu apoio, o Linux vai ficar mais organizado daqui pra frente.

[Kwezer]

Mas o Kernel 686 não reconhecia os processadores Dual Core?
Porque me falaram que o kernel 386 reconhece o processador Dual Core como Single Core...
Isso é real?

[greylica]

Os 686 sempre reconheceram SMP, somente o Pentium 4 é um diferencial pois ele não é dois núcleos Real, e sim uma emulação para evitar os gargalos de processamento e criar assimetria. Os kerneis 686 em sua maioria são preparados para trabalhar em máquinas multiprocessadas e isso é o ponto forte de toda plataforma *nix. Quanto á questão do I386 + SMP, alguns kerneis foram montados especialmente para fazer SMP através de Layers e criar Numa Links unindo as memórias em ambientes de máquinas heterogêneas, ( cluster dynebolic ) e não podemos esquecer que o Pentium Pro e alguns 486 Biprocessados existiram para o Windows NT também. Mas isso é coisa do passado e quese ninguém mais usa isso. Remonta dos tempo do conectiva 5 os Pentium Pro e os 486 Multiprocessados.

[thiago e. de oliveira]

Compilar um kernel - the Ubuntu way:

http://under-linux.org/?p=6372

[GAN0ND0RF]

Compilei o kernel  pro meu processador amd6, o que aconteceu é que toda vez que eu mudo de  kernel tenho que  reinstalar os drivers da  nvidia, o driver do meu  modem não funcionou, nem recompilando da fonte  e do resto não vi muita diferença não, mas usei pouco ainda.

[thiago e. de oliveira]

Compilei o kernel  pro meu processador amd6, o que aconteceu é que toda vez que eu mudo de  kernel tenho que  reinstalar os drivers da  nvidia, o driver do meu  modem não funcionou, nem recompilando da fonte  e do resto não vi muita diferença não, mas usei pouco ainda.

O ideal é que você passe a usar um kernel apenas. Pois muitos drivers têm que ser compilados com o kernel em uso, principalmente o da NVidia e de modem (lembro quando usava o driver da SmartLink ). Enfim, usando um kernel só, dá pra você compilar tudo com base nele. Isso significa que esses drivers deixarão de funcionar no kernel anterior.

[GAN0ND0RF]

Tentei recompilar o driver da smart link, é o que uso no meu modem, no kernel 64 e não obtive êxito.
Eu tava pensando em instalar o kernel 64 junto com o 32, que era pra usar o 64 quando não fosse entrar na internet.
Mas dessa forma fica muito complicado.
Se tivesse como fazer meu modem funcionar no kernel 64, usaria só ele mesmo, pq o que o povo reclama do 64, no caso o flash e o java, alé de codecs eu num uso muito aqui.

Tem como criar um kernel 32 otimizado prum processador k8?

[KurtKraut]

Tem como criar um kernel 32 otimizado prum processador k8?

No artigo que escrevi postado pelo galactus aqui está claro que compilar otimizado para uma arquitetura não provoca ganho de desempenho relevante.