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

vampire_thunder · 11 de Fevereiro de 2011, 14:56

Citação de: Gunss online 11 de Fevereiro de 2011, 14:29
@vampire, o kernel que você passou é bom durante o uso do PC. Melhor que o kernel que eu compilei do .37, só que o patch do ureadahead não ta funcionando não, a inicialização ta demorando bastante, e quando aparece a área de trabalho também demora, mas depois de carregado tudo o sistema é bem ligeiro.
Mas parabéns pelo kernel. Vou procurar aqui como fiz para ativar o "Trace events bla bla bla"

Nossa, aqui está bem rápido. Se não está habilitado, então imagina quando estiver. Se souber aonde habilita, por favor me diga

Stivekx · 11 de Fevereiro de 2011, 15:41

@4d4c47
Po, valeu

:D

@vampire_thunder
Então, o diff poderia fazer o que a gente mexe muito aqui (um .patch)
Eu pensei em fazer isso, só que a intenção era procurar todos os arquivos que tenham o mtune ou march e dar esse "replace", Isso é meio perigoso porque como o cara falou, tem arquivos responsáveis pelo video. ;s
O patch séria legal, mas teria que saber quais arquivos dar patch, e nas próximas versões do kernel pode ser que essas linhas sejam removidas, ou novas linhas sejam adicionadas, tendo que fazer um script que procure essas linhas novas e crie um novo patch, o que mais vale rodar o script, hm1

Gunss · 11 de Fevereiro de 2011, 15:45

Citação de: Stivekx online 11 de Fevereiro de 2011, 15:41
@vampire_thunder
Então, o diff poderia fazer o que a gente mexe muito aqui (um .patch)
Eu pensei em fazer isso, só que a intenção era procurar todos os arquivos que tenham o mtune ou march e dar esse "replace", Isso é meio perigoso porque como o cara falou, tem arquivos responsáveis pelo video. ;s
O patch séria legal, mas teria que saber quais arquivos dar patch, e nas próximas versões do kernel pode ser que essas linhas sejam removidas, ou novas linhas sejam adicionadas, tendo que fazer um script que procure essas linhas novas e crie um novo patch, o que mais vale rodar o script, hm1

Esse lance de alterar parte de vídeo, lendo pela net vi que somente para arquitetura PPC e ARM. Como usamos x86 ta tranquilo.

Stivekx o script que você passou só ta alterando o mtune para -march=native, será que estou usando ele certo? o
ps: esquece foi um uma "/" que removi ai o caminho ficou quebrado hehe

vampire_thunder · 11 de Fevereiro de 2011, 16:42

Citação de: Stivekx online 11 de Fevereiro de 2011, 15:41
@4d4c47
Po, valeu :D

@vampire_thunder
Então, o diff poderia fazer o que a gente mexe muito aqui (um .patch)
Eu pensei em fazer isso, só que a intenção era procurar todos os arquivos que tenham o mtune ou march e dar esse "replace", Isso é meio perigoso porque como o cara falou, tem arquivos responsáveis pelo video. ;s
O patch séria legal, mas teria que saber quais arquivos dar patch, e nas próximas versões do kernel pode ser que essas linhas sejam removidas, ou novas linhas sejam adicionadas, tendo que fazer um script que procure essas linhas novas e crie um novo patch, o que mais vale rodar o script, hm1

Geralmente não muda muita coisa, e o que dá erro ainda dá para corrigir, devido aos arquivos .rej que ele cria. É assim que eu aplico patches mais antigos, com o do LZMA, em versões novas.
Mas eu vou testar seu script e recompilar o kernel que, aliás, tenho gostado da velocidade e estabilidade. Para quem não conseguiu ver o tópico e baixar, aí vão os links:

http://archive.lineduc.sigeduc.info/lineduc/pool/main/l/linux/linux-headers-2.6.37-12_2.6.37-12.26.1_all.deb

32 bits
http://archive.lineduc.sigeduc.info/lineduc/pool/main/l/linux/linux-headers-2.6.37-12-lineduc2_2.6.37-12.26.1_i386.deb
http://archive.lineduc.sigeduc.info/lineduc/pool/main/l/linux/linux-image-2.6.37-12-lineduc2_2.6.37-12.26.1_i386.deb

64 bits
http://archive.lineduc.sigeduc.info/lineduc/pool/main/l/linux/linux-headers-2.6.37-12-lineduc2_2.6.37-12.26.1_amd64.deb
http://archive.lineduc.sigeduc.info/lineduc/pool/main/l/linux/linux-image-2.6.37-12-lineduc2_2.6.37-12.26.1_amd64.deb

A única coisa que percebi aqui no notebook (só uso notebook, não tenho desktop), é que a bateria vai embora. Creio que por conta da mudança para 300 HZ.

Stivekx · 11 de Fevereiro de 2011, 17:09

To pensando em fazer um script que ajude a fazer esse processo de recompilação do kernel, baixe, descomprimi, move pra /usr/src/, roda o script que muda pra -march=native, te dá uma lista com patchs, baixa "pactheia", dá uma lista de .configs (omnislash, default, liquorix).
Eu sei que tem o kernelcheck, mas ele não faz extamente o que a gente faz aqui, que aplicar os patchs, rs.
Só não sei se vale o trabalho de fazer um assim. hm1

@vampire_thunder
To baixando seu kernel, vou testar

Gunss · 11 de Fevereiro de 2011, 17:39

@vampire se a tua bateria vai embora assim tem que examinar o motivo. Não acho que o motivo seja a mudança para 300hz não.

victorwpbastos · 11 de Fevereiro de 2011, 17:41

Citação de: Stivekx online 11 de Fevereiro de 2011, 17:09
To pensando em fazer um script que ajude a fazer esse processo de recompilação do kernel, baixe, descomprimi, move pra /usr/src/, roda o script que muda pra -march=native, te dá uma lista com patchs, baixa "pactheia", dá uma lista de .configs (omnislash, default, liquorix).
Eu sei que tem o kernelcheck, mas ele não faz extamente o que a gente faz aqui, que aplicar os patchs, rs.
Só não sei se vale o trabalho de fazer um assim. hm1

@vampire_thunder
To baixando seu kernel, vou testar

rapaz, se vc fizer isso com certeza serei o primeiro a baixar esse script! não manjo muita coisa de bash mas se puder ajudar em alguma coisa estou disposto.

Stivekx · 11 de Fevereiro de 2011, 17:45

Testei esse kernel do vampire.
Bom, fiquei uns 15 minutos usando só mas a bateria aparentemente tá indo normal aqui.... ;s
Na questão do desempenho. O boot dele tá uns 3s mais rápido, mas na questão do desempenho abrindo programas, eu senti ele um pouco "lento", ao menos em comparação aos kernels que eu já compilei e testei. Mesmo com o driver de video instalado ele não teve um rendimento tãão bom quanto as minhas compilações usando 1000mhz, performance, low latency, bfs, bfq, unreadhead, o patch de 200 linhas.
Mas ele tá mais rápido que o kernel generic, aparentemente

vampire_thunder · 11 de Fevereiro de 2011, 22:48

Citação de: Stivekx online 11 de Fevereiro de 2011, 17:45
Testei esse kernel do vampire.
Bom, fiquei uns 15 minutos usando só mas a bateria aparentemente tá indo normal aqui.... ;s
Na questão do desempenho. O boot dele tá uns 3s mais rápido, mas na questão do desempenho abrindo programas, eu senti ele um pouco "lento", ao menos em comparação aos kernels que eu já compilei e testei. Mesmo com o driver de video instalado ele não teve um rendimento tãão bom quanto as minhas compilações usando 1000mhz, performance, low latency, bfs, bfq, unreadhead, o patch de 200 linhas.
Mas ele tá mais rápido que o kernel generic, aparentemente

Pô, valeu pela avaliação.

Os motivos para ele ser um pouco mais lento eu expliquei lá no fórum. E com certeza com 1000mhz, performance e low latency ficará mais rápido, mas aí é que a bateria vai embora mesmo.

Falando em Ureadahead, já descobriram aonde eu habilito?

Mais uma vez obrigado pela avaliação.

galactus · 12 de Fevereiro de 2011, 02:14

vampire_thunder, testei o seu kernel lineduc 2.6.37 64 bits no trabalho (Atom 330 - BubleBee) e em casa (Core i7)!

Em comum com os dois foi o erro durante a instalação do kernel Headers! Simplesmentes acusa falta de dependências! Qual? O próprio kernel headers! É, isso mesmo, ele diz que para instalar o kernel headers 2.6.37 ele precisa do kernel headers 2.6.37! Eu tenho o DKMS e o virtual box instalados nas duas máquinas! No trabalho é o ubuntu 10.04 e em casa (no momento) está o Mint 10. Não sei se isso tem alguma coisa haver!

Portanto, nos dois casos, o kernel headers está quebrado para o sistema!

Mesmo com este erro eu continuei, reiniciei o sistema já que o image não deu erro algum e ele foi adicionado no grub dos dois sem problema algum!

Nas duas distros não houve erro no boot e não notei nem aumento e nem diminuição no tempo do boot! Então, "parece" que o Ureheadread funcionou! O boot de ambos continuaram com seus temas gráficos característicos!

Na hora de carregar o Gnome, do GDM para a tela do desktop, notei que foi mais rápido que o kernel padrão do Ubuntu ou do Mint, mas perde para o do Liquorix e principalmente para o do HQx no PC de casa!

O consumo de RAM inicial ficou em torno de 256MB! Mais que o do Liquorix, mas menos do que o do Hqx!

No desempenho geral as coisas foram muito diferentes! No Atom eu notei uma melhora considerável na hora de abrir e fechar programas, e quando forço o sistema nos meus testes básicos!

Ele bugou o som do Xine quando abro arquivos .flv e a janela do SMplayer, não consigo mover sua janela, fica "colada" no lado superior esquerdo da tela! Como você usa 300Mhz ao invés dos 1000Mhz que eu uso no Atom, quando chamo muitas coisas ao mesmo tempo, as vezes ele é mais lento que o Kernel do HQx, mas não houve nenhuma travada e nenhum Lag nas imagens e no Som! Eu testei primeiro no trabalho, baixei os dois binários e gravei no PenDrive para testar em casa também!

Acreditei que correria tudo muito bem em casa, já que no "pobre" Atom a coisa fluiu bem, né!

Ledo engano! Apesar do boot e normal e na hora de carregar o Desktop do Gnome ele ter ficado entre o Liquorix e o do HQx, no restante ele começou a fazer água! Na parte de multimídia foi uma decepção! O core i7 engasgou nos vídeos e no som ao estar escaneando a minha coleção de músicas ou de fotos ao mesmo tempo em que chamo vídeos e músicas! Essa foi uma proeza digna de nota, pois nem o kernel lerdo do Ubuntu conseguiu essa façanha no Core i7 em Overclock de 3.8GHz! No som só aconteceu uma vez, mas o vídeo continuou ruim mesmo sem estar usando intensamente o HD! Os vídeos não eram fluidos seja lá qual for o reprodutor escolhido! Pra navegar na internet as animações não eram fluidas também, e rolar as páginas também não era fluído! Enfim, retirei rapidamente o seu kernel do PC de casa!

Hardware das duas máquinas:

Trabalho

Atom 330 (dois processadores a 1.6GHz)
2GB de RAM DRR2 800
HD de 500GB Samsung de 5400 rpm
Sistema de arquivos JFS tunado
Placa de vídeo OnBoard Intel
Som Intel
Rede sem Fio Atheros (funcionou direitinho)

Casa

Intel Core i7 860 (4 núcleos físicos mais 4 HT a 3.8GHz!)
4GB de RAM DDR 3 2000, mas funcionando a 1700
HD de 1TB Seagate 7200 rpm
Sistema de arquivos ext4 tunado + journal externo de 1GB num HD Hitachi de 1TB e 7200rpm
Placa de vídeo ATI Radeon 4850
Som Intel
Rede Gigabit Intel (também funcinou direitinho)

Quando compilo o kernel para meu PC de casa uso o Trio maravilha e todos os drivers do meu hardware dentro do kernel!

Agora me diga você vampire, porque esse comportamento tão dispare entre uma configuração que parece um fusca perto de uma Ferrari?

Quero pedir desculpas ao HQx pelos longos cometários de outro kernel aqui neste tópico!

Vampire, qual o seu tópico no Forum do Linueduc?

O que eu tenho observado e cada vez mais me convencido, é que o Kernel Omnislash, depois de ter acertado a mão na compilação do meu hardware, mais as modificações do march=native para o i7 é sem dúvida nenhuma o mais rápido para chamar programas individualmente! O kernel do HQx peca na hora de exigir dele intensa atividade de I/O nos discos rígidos ou em PenDrives e na Rede! O sistema não responde tão bem como quando eu uso CFQ! É nisso que o kernel do Liquorix ganha! O consumo de RAM dele também é mais alto ao usar o march=native, mas em compensação, ele usa esse consumo extra para te dar muita, mas muita velocidade mesmo! Meu amigo ficou boquiaberto na abertura do Google Chrome aqui! É clicar e aparecer! E com 10 ou 12 páginas abertas ao mesmo tempo!

Era isso!

Gunss · 12 de Fevereiro de 2011, 02:36

@Galactus so irei comentar agora sobre o ultimo paragrafo.

Há algum tempo conversei com o HQx e ele disse que o kernel Linux é feito pelas grandes empresas (disso todos sabem) como Intel, HP, AMD, IBM, Red Hat, Novell, desenvolvedores que trabalho no ramo de servidores, e do que eles precisam? De um CFS + CFQ ou de um BFS + BFQ?

O kernel padrão vem para trabalhar bem em grandes cargas, utilizando-se de vários processadores, discos, redes. Já o BFS e o BFQ querem trazer um desempenho de baixa latência, para sistemas pequenos e desktops onde a interatividade com o usuário é o interessante. Programas abrindo o mais rápido possível é o foco, diferente dos servidores onde o sistema se manter ROCK SOLID é o bom.

Para você o maior consumo de ram do -march=native não deveria preocupar. 4GB de ram po! Eu aqui com 1GB e ainda puxando o danado hehehe.

ps: Hoje fiz meu primeiro programa em C++. Daqui pro fim do semestre eu faço algo de util!

ps2: vampire, eu passo como habilitar o Uheadaread amanhã, perdi o fio da meada hoje "programando" hauahuah

Abraços.

vampire_thunder · 12 de Fevereiro de 2011, 04:52

Galactus, o tópico é esse:
http://forum.lineduc.ctics.sigeduc.info/viewtopic.php?f=20&t=391

Criei lá justamente para evitar esses comentários sobre outro kernel no tópico do Omnislash. Até porque não quero ser concorrente. Meu objetivo, inclusive colocando em prática o que aprendo aqui, é de colocar um kernel melhor numa distro.
Bizarro o que aconteceu no seu i7. Eu já estava ficando feliz, rsrsrsrsrs.
Mas seus problemas parecem ter a ver com o vídeo. A aceleração estava ativa (direct rendering: Yes)? Meu parceiro de desenvolvimento também tem um i7 (Notebook) no qual o vídeo não ativava, mas depois que instalamos o driver da ATI, tudo ficou perfeito. Quanto a quebra do headers, eu sempre instalo os 3 pacotes ao mesmo tempo no terminal, com dpkg -i, e nunca acusou quebra.

Estou satisfeito com os comentários. Agora vou rodar aquele script e compilar com march=native para ver se muda algo.

Agradeço a atenção e colaboração de todos. Aprendo bastante com vocês.

PS: Galactus, agora que me toquei numa coisa. Você instalou o pacote linux-headers-2.6.37-12_2.6.37-12.26.1_all.deb antes de instalar o headers 64?

galactus · 12 de Fevereiro de 2011, 09:58

Vampire, voltei a baixar o headers all.deb, e dessa vez não deu erro!

Vou voltar a refazer os testes, deixei o PC de casa com o seu kernel e estou usando ele agora no trabalho com tudo instalado como se deve! O próximo relato vai ser no seu tópico!

Gunss, quando relato o consumo de RAM maior não estou reclamando dele não, é para relatar o ocorrido mesmo!

Se o consumo for maior e a velocidade crescer com ele, até que é bem aceitável, mas não pode subir demais também!

Parabéns pela programação Gunss! Daqui a pouco o Gunss cria o kernel dele e desbanca o tio Linus!

vampire_thunder · 12 de Fevereiro de 2011, 10:23

Citação de: Stivekx online 10 de Fevereiro de 2011, 23:10
Tava voltando umas páginas, alguém pediu se dava pra dar um "replace" em todos os arquivos do kernel que contenha algum -march,-mtune,-mcpu, por -march=native.

Bom, eu não sou um eeexpert em bash, eu tenho lógica de programação porque programo em PHP.
Fiz esse script, ele é bem POG (programação orientada a gambiarra), devido a eu não ser muito bom em bash.
Ele dá o replace em todos os mtune march, mcpu por -march=native.

Se alguém quiser testar:
Código Selecionar Expandir
#!/bin/bash grep -srin mtune /usr/src/linux-2.6.37/* -l | while read path; do if [ "$path" != "/usr/src/linux-2.6.37/script.sh" ]; then echo $path sed -e 's/-mtune=.*/-march=native/g' $path > "$path.file_changed" rm -rf $path mv "$path.file_changed" $path fi done grep -srin march /usr/src/linux-2.6.37/* -l | while read path; do if [ "$path" != "/usr/src/linux-2.6.37/script.sh" ]; then echo $path sed -e 's/-march=.*/-march=native/g' $path > "$path.file_changed" rm -rf $path mv "$path.file_changed" $path fi done

PS.: Ele vai te dizer (ao menos é pra dizer) que arquivos ele mudou, depois de ele mudar, verifique a integridade do arquivo, com o backup que você deve ter feito do source do kernel. Tenha certeza que ele só deu replace no que deve. Isso é só pra testar claro. Eu testei com todos os arquivos (fiquei 20 min codando e 1 hora testando '-') e fez tudo que ele deveria sem problemas, mas pode ser que tenha algum erro, melhor testar.

PS2.: Se você fizer na pasta do src vai ter que executar ele como root

PS3.: se você fizer isso na pasta de outro kernel (eu fiz na do linux-2.6.37), tenha certeza de mudar todos os caminhos do script, pra não dar erro. E caso você mude o caminho, tome MUITO cuidado com o que vais remover porque eu uso: rm -rf, se você usar um rm -rf /, já era, rs. Por isso tome cuidado ou não execute como root, coloque em uma pasta que seu user tenha permissão.

PS4.: O script leva uns 10 minutos pra executar, isso é normal já que ele vai procurar 3 vezes em toooodos os arquivos do kernel ;x

Acabei de rodar o script e fui conferir o arch/x86/Makefile_32.cpu, onde tem mais entradas alteradas. Percebi que ele não fechou os parênteses. Vejam por exemplo, a partir da linha 30:

Original

Código Selecionar

cflags-$(CONFIG_MWINCHIPC6)	+= $(call cc-option,-march=winchip-c6,-march=i586)
cflags-$(CONFIG_MWINCHIP3D)	+= $(call cc-option,-march=winchip2,-march=i586)
cflags-$(CONFIG_MCYRIXIII)	+= $(call cc-option,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
cflags-$(CONFIG_MVIAC3_2)	+= $(call cc-option,-march=c3-2,-march=i686)
cflags-$(CONFIG_MVIAC7)		+= -march=i686
cflags-$(CONFIG_MCORE2)		+= -march=i686 $(call tune,core2)
cflags-$(CONFIG_MATOM)		+= $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \
	$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))

Depois do script

Código Selecionar

cflags-$(CONFIG_MWINCHIPC6)	+= $(call cc-option,-march=native
cflags-$(CONFIG_MWINCHIP3D)	+= $(call cc-option,-march=native
cflags-$(CONFIG_MCYRIXIII)	+= $(call cc-option,-march=native
cflags-$(CONFIG_MVIAC3_2)	+= $(call cc-option,-march=native
cflags-$(CONFIG_MVIAC7)		+= -march=native
cflags-$(CONFIG_MCORE2)		+= -march=native
cflags-$(CONFIG_MATOM)		+= $(call cc-option,-march=native
	$(call cc-option,-march=native

Alguém já conseguiu compilar depois dessas alterações? Deu erro de compilação ou foi de boa?

Gunss · 12 de Fevereiro de 2011, 12:21

Citação de: galactus online 12 de Fevereiro de 2011, 09:58
Vampire, voltei a baixar o headers all.deb, e dessa vez não deu erro!

Vou voltar a refazer os testes, deixei o PC de casa com o seu kernel e estou usando ele agora no trabalho com tudo instalado como se deve! O próximo relato vai ser no seu tópico!

Gunss, quando relato o consumo de RAM maior não estou reclamando dele não, é para relatar o ocorrido mesmo!

Se o consumo for maior e a velocidade crescer com ele, até que é bem aceitável, mas não pode subir demais também!

Parabéns pela programação Gunss! Daqui a pouco o Gunss cria o kernel dele e desbanca o tio Linus!

poxa, foi um calcular a resistencia equivalente em paralelo haeuaehuahe.

@Stivekx eu percebi isso também, hoje vou tentar compilar.