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

[worm83]

Tem diferença sim!  Com o 64bits ele aproveita muito melhor o cache!  Abertura e carregamento de fotos e vídeos são mais rápidos no 64bits!

Opá, valeu, sempre tive essa curiosidade.
.
Achei um texto interessante na net.
Interessante, pois não sabia a utilidade de alguns detalhes aplicados no kernel.

FONTE: https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/dica_r_C3_A1pida_otimiza_C3_A7_C3_A3o_de_desktops_com_kernel_linux_no_proc_e_sys81?lang=pt_br

[hiltongil]

http://ubuntuforum-br.org/index.php/topic,29799.msg375471.html#msg375471

ta ai o tudo do HQxriven.

Boa sorte 

Valeu Gunss.
E vamos aos testes então. Posteriormente posto os resultados e desastres! 

[Gunss]

http://ubuntuforum-br.org/index.php/topic,29799.msg375471.html#msg375471

ta ai o tudo do HQxriven.

Boa sorte 

Valeu Gunss.
E vamos aos testes então. Posteriormente posto os resultados e desastres! 

lembrando. Tenha ao menos a partição /home separada. Se for em outro HD melhor ainda.

[vampire_thunder]

Ah, sim, esqueci de divulgar:
http://forum.lineduc.ctics.sigeduc.info/viewtopic.php?f=2&t=382

[galactus]

Ah, sim, esqueci de divulgar:
http://forum.lineduc.ctics.sigeduc.info/viewtopic.php?f=2&t=382

Nossa que legal!   

Pô, fiquei muito feliz agora!  Aquela pesquisa toda deu resultado! 

De nada filipo!

E a você também vampire!

Vou procurar baixar a iso da distro pra testar!

[Alyscom]

Será que teremos uma versão do patch Omnislash para a versão 2.6.36 nos próximos dias?? rsrs

Abraços

[buli]

Será que teremos uma versão do patch Omnislash para a versão 2.6.36 nos próximos dias?? rsrs

Aqui vão umas primeiras impressões: dos kernels da última safra, o melhor de eles me parece o 34. O 35 estava ruim, pelo menos do 35.4 até o 35.7. Foi por isso que começei a experimentar com o 36 tão cedo. Porém, o que vi até agora não me deixou muito satisfeito, e os patches CK e BFS não ajudaram muito.

Aquela diminuição de 20 para 5 no dirty_ratio do CK deixou o sistema com muitos travamentos, pelo menos no hardware que testei. Nunca vi o Linux travar tanto. Sempre que dou boot volto para o default:

sysctl -w vm.dirty_ratio=20

Mas mesmo assim o sistema não fica fluido, como no 34.

Somente teve uma coisa boa inesperada que me surprendeu muito: o tempo de boot caiu quase 10 segundos, de 44 para 34, aproximadamente, no Debian lenny, sem optimizações, nem ureadahead.

Já que estamos falando do ureadahead, o patch funcionava bem, mas na hora da compilação o gcc dava um warning, não sei se no Ubuntu também:

---------------------------------------------
 CC      fs/exec.o
fs/exec.c: In function 'open_exec':
fs/exec.c:709: warning: passing argument 1 of 'trace_open_exec' discards qualifiers from pointer target type
include/trace/events/fs.h:66: note: expected 'char *' but argument is of type 'const char *'
-----------------------------------------------

isso aí e por causa do patch do readahead, pois é ele que cria esse arquivo fs.h. Aí consegui eliminar o warning com a seguinte modificação: na linha 709 do arquivo fs/exec.c trocar onde diz:

trace_open_exec(name);

pela seguinte nova chamada:

trace_open_exec((char *)name);

O (char *) antes do name é que se chama um "cast" e serve para trocar diferentes tipos em C,  por exemplo de int para float, etc.

O Kolivas tem vários outros patches no site dele:

http://ck.kolivas.org/patches/bfs/bfs357-latency_bias.patch
http://ck.kolivas.org/patches/bfs/bfs357-penalise_fork_depth_account_threads.patch

e também tinha um outro chamado bfs357-schedule_groups_as_entity-1.patch, mas ele tirou. Somente sobreviviou uma versão incorporada no bfs357 para o kernel 35.7 no link:

http://ck.kolivas.org/patches/bfs/2.6.35/2.6.35.7-sched-bfs357+schedule_groups_as_entity-1.patch

Aqueles patches acima parecem interesantes. O latency_bias mexe na latencia dependendo do workload, aparentemente. Contudo, não entram fácil. Tive que fazer várias mudanças para aplicar e compilar. Posso passar depois, se alguem tiver coragem de experimentar, mas são coisas muito instáveis, até o Kolivas tirou o schedule_group do site.

[Alyscom]

Obrigado pelo esclarecimento, buli!
Você me fez abrir a mente, fazendo com que eu entenda melhor o funcionamento dessa nova versão de kernel!
O único porém é que no momento eu estou impossibilitado de compilar alguma coisa no meu desk (pouco espaço em disco)!


[]'s


Alyscom

[hiltongil]

lembrando. Tenha ao menos a partição /home separada. Se for em outro HD melhor ainda.

Sim.. sim... tenho um HD já separado para testes não quero comprometer meus dados. Primeiro vou pegar aprendizado depois me arrisco no sistema que uso no dia-a-dia. 

[dss-ubuntu]

Oi buli, sei que aqui não é o lugar certo para fazer essa pergunta, mas se tiver um lugar melhor me avise.
Como posso compilar o kernel .34 no Lenny?

[buli]

Oi buli, sei que aqui não é o lugar certo para fazer essa pergunta, mas se tiver um lugar melhor me avise.
Como posso compilar o kernel .34 no Lenny?

Acredito estarmos no lugar certo, pois ninguém entende melhor do kernel do que o Hqxriven. Eu sempre sigo as dicas dele. Por exemplo tem esse link:

http://ubuntuforum-br.org/index.php/topic,29799.msg375471.html#msg375471

que um usuário citou nesta mesma página. Tente seguir as dicas dele e se der alguma coisa errada, você poderia postar aqui no tópico.

No Debian Lenny instalado de zero, acho que você pode ter os seguintes problemas:

1. O header utsrelease.h não é encotrado no lugar certo, pois o pacote kernel-package está desatualizado: Este problema pode ser resolvido com esse patch (eu achei essa dica aqui neste tópico):

http://launchpadlibrarian.net/37497839/kernel-package-2.6.33.patch

que tem ser aplicado com strip level igual a zero, ou seja com a opção -p0 no comando patch, como nesse exemplo:

Código Selecionar Expandir


patch -p0 --dry-run <kernel-package-2.6.33.patch && patch -p0 <kernel-package-2.6.33.patch


2. O header eventfd.h está faltando: Eu peguei esse header no pacote:

http://security.debian.org/debian-security/pool/updates/main/l/linux-2.6/linux-headers-2.6.26-2-common_2.6.26-21lenny4_i386.deb

e simplesmente coloquei ele na pasta /usr/include/sys/. Veja bem, eu não instalei o pacote. Somente fiz o download, abri ele com o dpkg, peguei apenas esse header e copiei no lugar que o gcc estava reclamando.

[Gunss]

agora que você comentou buli...

na hora de aplicar o patch do HQxriven nós usamos o comento -p1

o que esses "strip level" significam?

[dtomadon]

Então, após algum tempo usando o omni .34 posso fazer algumas considerações.
Como tinha postado em um comentário anterior o desempenho dele apresentou uma melhora perceptível, contudo o uso de memória se comparado com o kernel original é maior. Também notei que utilizando o omni eu tive alguns travamentos quando desconectava minha internet 3g (modem sony ericsson md300) e travava geral só enfiando o dedo e desligando. Utilizando o kernel generic não ocorreu isso. Ainda não tive coragem de compilar um kernel para a máquina só utilizei os debs disponibilizados pelo HQx (mão na roda com certeza). Também acompanhei que não existe uma "receita pronta" para todo e qualquer hardware, mas gostaria de saber se vocês tem algumas indicações para a compilação para um:
Notebook acer aspire 5050-3371
Proc: Turion64, MK-36, 512k cache L2
Video ATI Xpress 1100
1gb de ram 667mhz
hd 80 gb hitachi
SO LinuxMint 9
Antecipo já os agradecimentos a toda e qualquer ajuda.

Modem 3g e o omnislash batem de frente mesmo... Possivelmente o kernel padrão tem algum patch que desconhecemos ou é um bug do próprio 2.6.34.

Em relação a configuração eu te pergunto:

O que vc procura??

1 - Maior autonomia da bateria

2 - Maior performance com autonomia média

No caso 1 vc teria que provavelmente tirar o BFQ e fazer alguns testes colocando o hz em 100 e sem prempt.

No caso 2 vc teria que utilizar o omnislash e testar várias configs (aí é osso)

Hehehe meu amigo ,como andas só pra informação sempre usei modem 3g desde a versão 8.10 e sempre com seu kernel, só não testei ainda na 10.10
estou usando o kubuntu 10.10 ( kernel 2.6.35.22 ) adicionado os repositórios do Big Linux , se puder tirar essa dúvida quero compilar o omnislash novamente e um ótimo feriado a todos!!!

[galactus]

Senhores, acabo de compilar um novo Omnislash para o meu i7 com o BFS 357 mais o patch do Ureheadaread do fórum do Gentoo!

Usei o trio de sempre: Low-latency, 1000Mhz e performance! Em processador P4! Sistemas de arquivos dentro do kernel, no caso aqui é o ext4!

Nos meus testes preliminares só tenho uma palavra a dizer:  Sensacional! 

O BFS 357 deixou o i7 ainda mais rápido! Nunca vi o Picasa abrir com um piscar de olhos!   

Vou continuar os testes neste final semana para testar a estabilidade do sistema e quanto ele consome de RAM! O tempo de boot não mudou! Continua na casa dos 20 segundos!

Boa noite e bom Feriado a todos também!

[Gunss]

nossa, galactus sempre consegui melhorar o PC turbinado dele  

eu acho que não consigo mais desempenho pq eu gosto de efeitos básicos do compiz como minimizar e maximizar (e só estes também, aquelas besteiras de cubo acho tosco).

Também uso o tema elementary com o painel negro (lindão  ), e uso o metacity.
Ta na hora de começar a mexer no código do gnome  


ps: alguém já usou aquele phoronix-test-suite pra tentar medir o ganho de um kernel para outro?

ps2: alguém usa o tuxonice?