Kernel Omnislash (Unofficial) - Aprendendo a voar sem segredos!!!

[galactus]

testei os patchs passados pelo buli.
Todos os testes foram feitos no ubuntu 11.04 beta 2 atualizadíssimo.

Por incrível que pareça, na minha máquina mais modesta com apenas 1GB de ram e um HD que já ta pedindo descanso o sistema responde melhor a cargas mais altas de trabalho com o kernel padrão, lembrando que esse kernel é o 2.6.38 padrão do ubuntu 11.04.

O processador um Core 2 Duo e7200 não é problema. Acredito que nenhum processador do nível deste para cima tenham problemas em usar um kernel preempt + 300hz, é uma combinação de sucesso. Porém quem conta com um HD que tem menos cache, e pouca memória, ainda mais sendo uma memória mais lenta, o uso do BFS + BFQ + X com prio RT + o latnice (este usado com bastante moderação), não é sábio pois o sistema já sobe consumindo mais memória, observando o Htop vi que o uso de memória beira quase sempre os 100% ( memória alocada + memoria "cache"). O BFQ puxa tanto do HD que qualquer puxada mais forte ele não aguenta e trava todo o sistema.
Logicamente que essa lentidão eu percebo ao abrir o Firefox + banshee + broffice ao mesmo tempo, o sistema já abre os programas travando. Se eu abrir apenas um programa por vez e não puxar do sistema (como fazer uma grande atualização ou fazer um decode de um filme) a combinação de patchs é mais rápida, mas como sempre estou puxando bastante do sistema o kernel padrão até agora esta dando um show de bola.
Um bom teste é tentar compactar uma basta com uns 500MB com o lrzip feito pelo CK usando a opção -z, se seu sistema não der absolutamente nenhum lag e ficar totalmente fluido, você pode ter certeza que melhor ele não tem como ficar, pq além de usar 100% de todos os núcleos do processador, toneladas de RAM o danado ainda come muuuuita banda do HD.

Eu desafio o Galactus a conseguir deixar o sistema dele, que tenta deixar RT o máximo possível à resistir a esse teste.

Ainda não testei o uso do BFS + CFQ, já que o problema é o HD e a memória.
Se alguém aqui possuir um processador do mesmo nível do meu, porém com mais quantidade de memória e um HD poderia constatar realmente isso.

ps: sei que escrevi demais e enrolei mais do que escrevi, porém queria dividir logo a experiencia das 6 combinações diferentes de kernel que testei durante o dia.

Gunss estou baixando o lrzip para testar!  Vou fazer vários testes com os diferentes kerneis que tenho instalado aqui! Só agora que cheguei em casa, então vou aproveitar o feriado para fazer testes!

[Gunss]

testei os patchs passados pelo buli.
Todos os testes foram feitos no ubuntu 11.04 beta 2 atualizadíssimo.

Por incrível que pareça, na minha máquina mais modesta com apenas 1GB de ram e um HD que já ta pedindo descanso o sistema responde melhor a cargas mais altas de trabalho com o kernel padrão, lembrando que esse kernel é o 2.6.38 padrão do ubuntu 11.04.

O processador um Core 2 Duo e7200 não é problema. Acredito que nenhum processador do nível deste para cima tenham problemas em usar um kernel preempt + 300hz, é uma combinação de sucesso. Porém quem conta com um HD que tem menos cache, e pouca memória, ainda mais sendo uma memória mais lenta, o uso do BFS + BFQ + X com prio RT + o latnice (este usado com bastante moderação), não é sábio pois o sistema já sobe consumindo mais memória, observando o Htop vi que o uso de memória beira quase sempre os 100% ( memória alocada + memoria "cache"). O BFQ puxa tanto do HD que qualquer puxada mais forte ele não aguenta e trava todo o sistema.
Logicamente que essa lentidão eu percebo ao abrir o Firefox + banshee + broffice ao mesmo tempo, o sistema já abre os programas travando. Se eu abrir apenas um programa por vez e não puxar do sistema (como fazer uma grande atualização ou fazer um decode de um filme) a combinação de patchs é mais rápida, mas como sempre estou puxando bastante do sistema o kernel padrão até agora esta dando um show de bola.
Um bom teste é tentar compactar uma basta com uns 500MB com o lrzip feito pelo CK usando a opção -z, se seu sistema não der absolutamente nenhum lag e ficar totalmente fluido, você pode ter certeza que melhor ele não tem como ficar, pq além de usar 100% de todos os núcleos do processador, toneladas de RAM o danado ainda come muuuuita banda do HD.

Eu desafio o Galactus a conseguir deixar o sistema dele, que tenta deixar RT o máximo possível à resistir a esse teste.

Ainda não testei o uso do BFS + CFQ, já que o problema é o HD e a memória.
Se alguém aqui possuir um processador do mesmo nível do meu, porém com mais quantidade de memória e um HD poderia constatar realmente isso.

ps: sei que escrevi demais e enrolei mais do que escrevi, porém queria dividir logo a experiencia das 6 combinações diferentes de kernel que testei durante o dia.

Gunss estou baixando o lrzip para testar!  Vou fazer vários testes com os diferentes kerneis que tenho instalado aqui! Só agora que cheguei em casa, então vou aproveitar o feriado para fazer testes!

olha, esse lrzip é PESADO, porém comprime bem viu... o CK zipou todos os kerneis da série 2.6 (2.6.0 até o 2.6.38) e o tamanho total foi de 160MB.
Aqui usando flags mais leves, zipei o código do wine 1.3.18 compilado de 500MB para 54MB, o 7z zipou em 75MB e o bz2 em 100MB.

[galactus]

Gunss, me manda os comandos pra fazer esse lrzip funfar!  Ele não quer funfar aqui!



Edit:

Obrigado Gunss pelos comandos!  Estou no momento aqui com o Buble Bee comprimindo uma pasta de fotos com 800MB, Google chrome com 14 abas abertas, gcalculator e ouvindo música com o Rhytmbox numa boa! Sem travadas ou Lags!

É claro que o sistema ficou mais lento, mas não perdeu a fluidez! O Htop indica um consumo praticamente padrão nos "4 núcleos" do Atom 330 de 30%! Estou unsado a opção -z que você falou!  Acho que o i7 vai tirar isso de letra!  

Edit1:

Olha aqui uma foto pra não dizer que eu inventei:



Edit2: Compactação terminou agora pouco, demora pra burro mesmo!  Reduziu a pasta de 800MB para 625MB de fotos jpg!

[Gunss]

comprime mesmo esse lrzip né??

Agora, eu só acho um motivo para ai ser fluido e aqui não... memória RAM, a diferença de 1GB para 2GB é crucial, 1GB deixa tudo muito apertado, com 2GB pode se dar ao luxo de regalias.

[vampire_thunder]

Postem os comandos aqui, para todo mundo conhecer.

Pelo que estão falando, já estou no aguardo de implementarem o lrzip no kernel, para criar LiveCDs com ele. Vai ser muito mais coisa em menos espaço.

[galactus]

Postem os comandos aqui, para todo mundo conhecer.

Pelo que estão falando, já estou no aguardo de implementarem o lrzip no kernel, para criar LiveCDs com ele. Vai ser muito mais coisa em menos espaço.

Tá na mão, aqui vai na integra o e-mail do Gunss me ensinando a usar o lrzip:

Fala Galactus!!!

cara, tem o read me na propria pasta do lrzip, mas o básico funciona assim:

lrzip nome_do_arquivo   -   Este só funciona com arquivos

lrztar nome_da_pasta    -   Este zipa somente pastas

existem os leveis de compactação, o padrão já puxa bastante, mas se quiser o TOP TOP TOP faz assim

lrzip/lrztar -z nomedoarquivo/pasta

se digitar lrzip --help você verá a lista completa de comandos, da pra escolher o nível de compactação do gzip e do bz2, porém eles não são padrões.


espero ter ajudado mais do que confundido hauhauhaua.

No meu caso para compactar a pasta Imagens com o grau de compactação máximo eu fiz:

Código Selecionar Expandir

$lrztar -z Imagens/

O processo demora pra burro e no início ele puxa muito recurso da máquina, mas depois estabiliza, o negócio é ter recursos de sobra no PC. Eu fiz o teste no i7 em casa e foi como eu disse, o sistema fica mais lento mas não perdeu a sua fluidez.  Agora é evidente que em casa os recursos sobravam muito, CPU, memória e múltiplos HDs.  No Atom 330 ele usava os "4 núcleos" como eu disse e mostrei! No i7 no início ele usa 4 dos 8 núcleos também, mas depois ele passa a usar apenas um em 100%!   Depois que o i7 coloca os aplicativos no seu cache ele abre as coisas da segunda vez como se praticamente eu não estivesse usando o lrzip! Guardando a devida proporção, o Atom também faz o mesmo! O  que achei legal é que por conta do CFQ + JFS, por incrível que pareça, o lrzip parece pesar menos no Atom, isso no uso geral do sistema!!!  Mas ele leva um tempo enorme para realizar a tarefa!  No i7 não, a porcentagem da compactação sobe rapidinho mas eu vejo que a luz do HD pisca muito mais e como eu disse a CPU vai a 100%!   

Há sim, você ainda pode usar o man lrzip para poder saber de todas a opções dele!

[Gunss]

Aqui ele usa 100% do meu C2D.

Uma nova correção no BFS, agora 0.401
http://ck-hack.blogspot.com/2011/04/bfs-0401.html


ps: tinha me esquecido como é compilar um kernel com o .config da distro... demora muuuito hahahha

[vampire_thunder]

Uma nova correção no BFS, agora 0.401
http://ck-hack.blogspot.com/2011/04/bfs-0401.html

Isso e o kernel 2.6.38.4 

[Gunss]

Uma nova correção no BFS, agora 0.401
http://ck-hack.blogspot.com/2011/04/bfs-0401.html

Isso e o kernel 2.6.38.4  

já??? putz...

to tentando compilar um kernel 64 bits aqui no meu sistema 32 bits mas não da certo, da erro na hora de criar o debootstrap...
"Failure trying to run: chroot /home/jussier/chroot/debian64 mount -t proc proc /proc"

[vampire_thunder]

Não eles não tiraram, outro membro aqui do Fórum me falou o mesmo! Como eu usei ele apenas como live-cd, não saí da sessão, então não pude ver isso no GDM
Trident de 1MB? Rapaz, você gosta mesmo de desafios!

No aguardo da narração!  

Olha ele aí:


Pois bem. Baixei o kernel no site oficial, na época (como se tivesse tanto tempo assim) o 2.6.38.2, e apliquei os patches do Ubuntu, LZMA, AUFS e BFS. Segundo sua dica, estou usando CFQ, e por isso não apliquei o patch do BFQ.
Segui as dicas do Gentoo e mudei apenas o Makefile da raiz, colocando as flags do processador, mais -march=native e -mtune=generic. Não alterei nenhum outro arquivo da pasta arch/x86.
No menuconfig, desabilitei apenas aquilo que eu tinha certeza absoluta que não ia usar nessa máquina: wireles, pcmcia e bluetooth. Escolhi a opção "K6" para o kernel e marquei a placa Trident como driver. Esse Burg colorido da foto é o burg-emu, já rodando com o kernel instalado. Quando o PC inicia, não consegue exibir o Burg com as corres corretas devido aos recursos parcos da placa de vídeo de 1 MB.
Durante a compilação, executei os comandos "ps ax | grep gcc | grep march" e "ps ax | grep gcc | grep mtune", me retornando -march=k6 e -mtune=generic32.

Mas depois de 5 horas de compilação, eis que dá erro na hora que tentou compilar o vmlinux. Faltou memória. Então resolvi arriscar uma coisa meio doida. Coloquei o HD na minha case, ligueo ao notebook, entrei como chroot e continuei a compilação. Resolvi executar novamente os comandos e adivinhem o que aconteceu? Retornaram os mesmos  -march=k6 e -mtune=generic32, mesmo eu estando em um PC totalmente diferente. Nem preciso dizer se funcionou. A foto está aí para mostrar

Portanto, Galactus, você pode usar seu i7 para compilar o kernel do Atom, desde que o Makefile esteja com as flags corretas. Isso também quer dizer que o kernel generic que compilei para o Lineduc realmente é generic, não pegando nenhuma configuração específica do meu CPU.

Estou agora instalando o lubuntu-desktop só para ver como fica. Mas sei que ficará uma M... porque só para baixar está demorando pacas. Pelo menos eu vi que é possível, além de descobrir sem querer essa questão na compilação

[vampire_thunder]

to tentando compilar um kernel 64 bits aqui no meu sistema 32 bits mas não da certo, da erro na hora de criar o debootstrap...
"Failure trying to run: chroot /home/jussier/chroot/debian64 mount -t proc proc /proc"

Você pode até conseguir compilar um kernel 32 bits estando num sistema 64 bits, mas nunca o contrário.

[galactus]

Não eles não tiraram, outro membro aqui do Fórum me falou o mesmo! Como eu usei ele apenas como live-cd, não saí da sessão, então não pude ver isso no GDM
Trident de 1MB? Rapaz, você gosta mesmo de desafios!

No aguardo da narração! 

Olha ele aí:


Pois bem. Baixei o kernel no site oficial, na época (como se tivesse tanto tempo assim) o 2.6.38.2, e apliquei os patches do Ubuntu, LZMA, AUFS e BFS. Segundo sua dica, estou usando CFQ, e por isso não apliquei o patch do BFQ.
Segui as dicas do Gentoo e mudei apenas o Makefile da raiz, colocando as flags do processador, mais -march=native e -mtune=generic. Não alterei nenhum outro arquivo da pasta arch/x86.
No menuconfig, desabilitei apenas aquilo que eu tinha certeza absoluta que não ia usar nessa máquina: wireles, pcmcia e bluetooth. Escolhi a opção "K6" para o kernel e marquei a placa Trident como driver. Esse Burg colorido da foto é o burg-emu, já rodando com o kernel instalado. Quando o PC inicia, não consegue exibir o Burg com as corres corretas devido aos recursos parcos da placa de vídeo de 1 MB.
Durante a compilação, executei os comandos "ps ax | grep gcc | grep march" e "ps ax | grep gcc | grep mtune", me retornando -march=k6 e -mtune=generic32.

Mas depois de 5 horas de compilação, eis que dá erro na hora que tentou compilar o vmlinux. Faltou memória. Então resolvi arriscar uma coisa meio doida. Coloquei o HD na minha case, ligueo ao notebook, entrei como chroot e continuei a compilação. Resolvi executar novamente os comandos e adivinhem o que aconteceu? Retornaram os mesmos  -march=k6 e -mtune=generic32, mesmo eu estando em um PC totalmente diferente. Nem preciso dizer se funcionou. A foto está aí para mostrar

Portanto, Galactus, você pode usar seu i7 para compilar o kernel do Atom, desde que o Makefile esteja com as flags corretas. Isso também quer dizer que o kernel generic que compilei para o Lineduc realmente é generic, não pegando nenhuma configuração específica do meu CPU.

Estou agora instalando o lubuntu-desktop só para ver como fica. Mas sei que ficará uma M... porque só para baixar está demorando pacas. Pelo menos eu vi que é possível, além de descobrir sem querer essa questão na compilação

Muito bom saber disso vampire! Agora eu não consigo ver as fotos!  Não tá aparecendo nada para mim! Mesmo copiando e colocando o link da foto direto!

Não sai um tuto de como compilar um kernel 32bits em uma máquina 64bits não? 

Já estou acabando o tuto reunindo toda as informações sobre as dicas de otimização do processador!

[galactus]

Atendendo a pedidos, aqui está o tuto sobre as dicas do Gentoo: http://ubuntuforum-br.org/index.php/topic,81718.0.html

Agora não vale mais reclamar que está tudo espalhado! 

[vampire_thunder]

Muito bom saber disso vampire! Agora eu não consigo ver as fotos!  Não tá aparecendo nada para mim! Mesmo copiando e colocando o link da foto direto!

Não sai um tuto de como compilar um kernel 32bits em uma máquina 64bits não?  

Já estou acabando o tuto reunindo toda as informações sobre as dicas de otimização do processador!

Não estava conseguindo porque a foto estava vindo direto do meu HD (no-ip) e eu fiquei off. Mas já upei e corrigi o link.

Para falar a verdade eu não sei compilar um kernel 32bits diretamente num sistema 64 bits. Eu faço isso com debootstrap + chroot. Para isso, basta seguir meu tutorial de como criar um LiveCD do zero, que está na Revista Espírito Livre. Eu tenho um sistema 32 bits "enjaulado" que uso só para compilar. E só dá para enjaular um sistema 64 bits dentro de outro 64 bits, nunca num 32 bits. O contrário já pode.

Quebrei a cara. O K6 ficou "ótimo" depois que eu instalei o lubuntu-desktop. Coloquei entre aspas porque realmente não tem como esperar muito dele, mas pela idade dessa máquina e pela quantidade de RAM, realmente está muito bom. Só a placa de vídeo que atrapalha muito. Se eu arrumasse uma mais "decente", ficaria ainda melhor.


Ah, sim. Também estou com problemas no ACPI. Aparece uma mensagem na tela, assim que sai do burg, dizendo que a bios é de 97, portanto anterior a 2000, e que eu precisaria usar acpi=force. Com isso o botão de desligar não está disponível no menu do LXDE. Estou desligando pelo terminal.

[Gunss]

@vampire, é pelo visto ta meio dificil então deu compilar esse kernel 64bits... tava precisando compilar esse kernel meio que com urgencia =/
o chroot pode ser usado para que exatamente?

@galactus
Como fazer cross-compile
http://linux.koolsolutions.com/2009/06/04/howto-cross-compiling-a-32-bit-i386-linux-kernel-on-64-bit-machine-amd64/

como funciona o chroot e o debootstrap
http://linux.koolsolutions.com/2009/05/15/howto-bootstrapping-debian-linux-system-using-debootstrap/

Valeu pelo tópico =)