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

[Gunss]

Eu sei que instalar um GCC diferente que vem na distro é muita aventura. Mas estou testando em uma instalação feita para isso então...

https://launchpad.net/ubuntu/+source/gcc-4.5/4.5.2-5ubuntu3
Aqui o GCC 4.5.2 que não sofre daquela regressão reportada aqui pelo Galactus, e o GCC foi compilado pela Canonical.
É só escolher a arquitetura e baixar.

No Ubuntu 10.04 vai ser mais chato de instalar, mas é só procurar no site http://packages.ubuntu.com/maverick que você acha tudo que precisa.

Depois é só setar o GCC 4.5.2 como padrão com o tutorial do galactus e pronto. Sucesso.
http://ubuntuforum-br.org/index.php/topic,76787.0.html

[Gunss]

compilei o kernel usando o GCC 4.4.3 com as seguintes flags

-O2 -pipe -fomit-frame-pointer -march=native -msse4.1 -mmmx --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=generic -fstack-protector

e ficou um LIXO. Tenho certeza que apenas 1GB de ram não ajudou em nada, pois o consumo aumentou bastante. Quem tiver 2GB de ram tirará melhor proveito com toda certeza. O acesso ao HD está muito lento.
Estou usando apenas o Ureadahead e o BFQ e o CFS + cgroups.

[vampire_thunder]

Eu também ando reparando que o 2.6.38 que compilei aqui com as flags ficou pior que o 2.6.37 que compilei sem as flags. Vou fazer uma nova compilação.


Off: então quer dizer que é isso que significa BFS:
http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler

[galactus]

Galera, pq o Sidux é tão rápido? Baixei os debs do kernel dele e instalei no meu debian mas não senti muita diferença. O que mais pode ter de diferente no Sidux?

O Aptosid, outrora Sidux, é muito rápido pois além do seu kernel tunado, seus pacotes são compilados para processadores modernos (i686)!

As distros RPM como o Fedora, Suse e Mandriva são i586! O Debian e o Ubuntu  ainda suportam i386!

Quando você tem um processador moderno com muito cache, pacotes compilados para i586 e i686 ficam um canhão! Principalmente se você chamar o programa da segunda vez ou fizer uso do Preload!

Galactus... desculpa a ignorancia.... mas nao achei download do sidux em i686. No release dele tem sim... mas nos sites de Download nao... sabe de algum link? Eu ia ate instalar no pc (uso quase s'o o note..)
Abrass.

Ricardo, o Sidux acabou!  Agora ele se chama Aptosid!

http://aptosid.com/

[Gunss]

Galera, pq o Sidux é tão rápido? Baixei os debs do kernel dele e instalei no meu debian mas não senti muita diferença. O que mais pode ter de diferente no Sidux?

O Aptosid, outrora Sidux, é muito rápido pois além do seu kernel tunado, seus pacotes são compilados para processadores modernos (i686)!

As distros RPM como o Fedora, Suse e Mandriva são i586! O Debian e o Ubuntu  ainda suportam i386!

Quando você tem um processador moderno com muito cache, pacotes compilados para i586 e i686 ficam um canhão! Principalmente se você chamar o programa da segunda vez ou fizer uso do Preload!

Galactus... desculpa a ignorancia.... mas nao achei download do sidux em i686. No release dele tem sim... mas nos sites de Download nao... sabe de algum link? Eu ia ate instalar no pc (uso quase s'o o note..)
Abrass.

Ricardo, o Sidux acabou!  Agora ele se chama Aptosid!

http://aptosid.com/

Agora é torcer para o Ricardo não ter a mesma sorte que eu tenho. Se eu quiser instalar o aptosid aqui terei que remover metade do meu sistema primeiro.

Ah. Compilei o kernel com o GCC 4.5.2, utilizei as flags

-march=native -msse4.1 -mmmx -mtune=native

e repeti essas flags para o C++

Tenho uma compilação aqui pronta para ser instalada com essas flags

-O2 -pipe -fomit-frame-pointer -march=native -msse4.1 -mmmx --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=native -fstack-protector

Quero testar essa compilação para ver se a mudança do GCC ajuda, pq o kernel com essas flags compiladas pelo 4.4.3 ficou uma derma!

[galactus]

Gunss, como é que ficou?

Dei uma parada nas compilações do Kernel, estou "refinando" o servidor e comecei a aprender a instalar o Stage 3 do Gentoo! Já baixei e descompactei coisa pra burro, usando tudo em terminal com o Links, e até agora nada da instalação propriamente dita!  

[Gunss]

hauahuahuhauha. Vai suar a camisa em!!! Um dia faço o mesmo.

Quanto à compilação. Acho que a utilização da flags -msse4.1 ou -mmmx ta dando derma. Só pode! Não acredito que o kernel tenha piorado tanto da versão .37.2 para a .37.3. A diferença é mesmo das flags.
O sistema NÃO aguenta uma carga mais alta de trabalho. A música para, os programas ficam rodando no soquinho na sorte!!!
A compilação feita com o GCC 4.5.2 ajudou, pq com o GCC 4.4.3 o sistema PARAVA DE VEZ!

E olha que o único programa que esta rodando aqui que consome mais CPU e memória é o LRZIP, feito pelo mesmo autor do BFS.
Estou compactando uma pasta de Temas para o sistema de 62MB, usando a opção -z que é a mais pesada e a mais demorada, porém tem maior taxa de compressão. Com o kernel .36 que tinha aqui ele aguentava essa compactação sem grandes problemas.

ps: A compilação com o GCC 4.5.2 realmente ajudou, pois agora o sistema esta configurado com 1000 Hz. O outro estava com 300 Hz e compilado com o GCC 4.4.3 e o sistema travava bem mais.

edit: No site do BFQ, o criador fala que o BFQ-V2 que tem no kernel .37, diminuiu ainda mais a latencia, talvez isso esteja ferrando meu sistema.

edit2: Para os interessados. GCC 4.6 é lançado.
http://gcc.gnu.org/
alguém vai encarar?

[galactus]

Alguém aqui já deu uma lida no novo teste com 7 sistemas de arquivos do Phoronix?

http://www.phoronix.com/scan.php?page=article&item=linux_2638_large&num=1


Depois de ter lido sobre o teste eu fui ler os comentários no Fórum!

Achei excelente ver o desenvolvedor chefe do EXT4 lá, respondendo dúvidas e prestando muitos esclarecimentos, criticando e elogiando o teste do Phoronix!

O cara dá uma aula, literalmente escreve redações em algumas repostas! Inclui ainda análises de desenvolvedores amigos dele da HP e da IBM! 

Ele deixa claro que sempre vai priorizar a segurança dos dados em detrimento do desempenho!  E faz uma crítica marcante mas com argumentos técnicos inquestionáveis, que o tipo de teste que o Phoronix faz não serve para escolher o sistema de arquivos ideal!  Isso porque o Phoronix não faz teste de um sistema de arquivos em produção, mas sim de um sistema recém instalado! Ele diz que procura sempre melhorar o ext4 no acesso de dados de forma randômica e evitar que ele se fragmente, mas sem nunca perder a segurança dos dados!

Pra quem sabe ler bem em Inglês, confira: http://phoronix.com/forums/showthread.php?36507-Large-HDD-SSD-Linux-2.6.38-File-System-Comparison

[Gunss]

Alguém aqui já deu uma lida no novo teste com 7 sistemas de arquivos do Phoronix?

http://www.phoronix.com/scan.php?page=article&item=linux_2638_large&num=1


Depois de ter lido sobre o teste eu fui ler os comentários no Fórum!

Achei excelente ver o desenvolvedor chefe do EXT4 lá, respondendo dúvidas e prestando muitos esclarecimentos, criticando e elogiando o teste do Phoronix!

O cara dá uma aula, literalmente escreve redações em algumas repostas! Inclui ainda análises de desenvolvedores amigos dele da HP e da IBM! 

Ele deixa claro que sempre vai priorizar a segurança dos dados em detrimento do desempenho!  E faz uma crítica marcante mas com argumentos técnicos inquestionáveis, que o tipo de teste que o Phoronix faz não serve para escolher o sistema de arquivos ideal!  Isso porque o Phoronix não faz teste de um sistema de arquivos em produção, mas sim de um sistema recém instalado! Ele diz que procura sempre melhorar o ext4 no acesso de dados de forma randômica e evitar que ele se fragmente, mas sem nunca perder a segurança dos dados!

Pra quem sabe ler bem em Inglês, confira: http://phoronix.com/forums/showthread.php?36507-Large-HDD-SSD-Linux-2.6.38-File-System-Comparison

Eu li. Realmente o cara foi muito legal.
Nós nos esquecemos que quem faz o Linux são as empresas que buscam o melhor sistema possível para seus servidores. Isso é uma moeda de dois lados.
O lado bom é que sempre teremos um sistema sólido e atualizado.
O lado não tão bom é que as vezes o sistema vai mais para um lado onde os desktops não ganham muito. O CFS + CFQ é um ótimo exemplo disso, eles priorizam sistemas com realmente muitas CPUs/HDs. Mas por se tratar de um sistema aberto, temos alternativas como BFS + BFQ. E isso é algo superficial, as vezes algumas diretrizes que o sistema de arquivos EXT4 toma não traz vantagem alguma para desktops, porém para servidores é ótimo. É assim que o bonde anda.


ah, kernel 2.6.38 lançado.

[Gunss]

Só uma pergunta. Alguém habilita essa opção no kernel? CONFIG_CC_STACKPROTECTOR?

Estou usando o kernel 2.6.38 vanilla. Com todas aquelas opções. E isso me deixa com mais certeza, se quiserem utilizar todas aquelas opções, tenha no mínimo 2GB de ram para sistemas 32bit. Sério, usando o lrzip que come muita RAM, HD e CPU, o consumo fica em uns 80%.

[Gunss]

https://github.com/poelzi/ulatencyd

== What is ulatency ==

Ulatency is a daemon that controls how the Linux kernel will spend it's
resources on the running processes. It uses dynamic cgroups to give the kernel
hints and limitations on processes.

It strongly supports the lua scripting language for writing rules and the
scheduler code.

== What tries it to fix ==

The Linux scheduler does a pretty good job to give the available resources to
all processes, but this may not be the best user experience in the desktop case.
ulatencyd monitors the system and categorizes the running processes into cgroups.
Processes that run wild to slow down the system by causing massive swaping will
be isolated.

Vou testar aqui!!

[galactus]

Pessoal, continuando aqui com minhas compilações com o Omnislash 2.6.34, fiz uma nova compilação com as dicas do Gentoo para o Buble Bee!

A linha em especial do Makefile do Kernel ficou assim:

Código Selecionar Expandir

TCC       = gcc
HOSTCXX      = g++
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -pipe -march=native -mcx16 -msahf -mmovbe --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=generic -fstack-protector
HOSTCXXFLAGS = -O2

Notem que eu preferi não colocar outras instruções além da saída do comando:

Código Selecionar Expandir

cc -march=native -E -v - </dev/null 2>&1 | grep cc1

A saída deste comando para o meu Atom 330 foi:

Código Selecionar Expandir

/usr/lib/gcc/x86_64-linux-gnu/4.4.5/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=atom -mcx16 -msahf -mmovbe --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector

Como podem ver eu mudei o -march para Native e o -mtune para Generic, também seguindo a dica do Gentoo!

Nos outros arquivos troquei todos os -march por native e -mtune  para generic, usei o GCC 4.4.5 no Lubuntu 10.10 64bits!

Nas opções "gerais" do menuconfig do Kernel eu usei: BFS + BFQ + Preempt + 1000Mhz + Ondemand!

O resultado no geral foi o seguinte:

Definitivamente, para quem gosta de resposta imediata desde a primeira vez que você chama programas, a opção P4 (para quem compila em 64bits) do menuconfig para o processador é melhor! Contudo, fiquei realmente impressionado ao ver a carga no processador diminuir quase pela metade quando fico com mais de 15 abas abertas em qualquer navegador aqui!  Com o P4 ele fica com um processador sempre em 25-27% e os outros "3" com 12-16%!  Quando fiz uso das opções que mostro logo acima, a carga de um deles fica sempre em 10-12% e os outros "3" em 6-9%! É uma queda significativa para um "caroço de azeitona"!  

Isso é fantástico para que tem algum Atom em Netbooks! Vai economizar muito mais bateria, e olha que usei 1000Mhz!

O resultado final é que a carga que posso colocar sobre o sistema aumentou antes dele dar" Lag" ou travar! Ele não abre os programas tão rápido da primeira vez como com o P4, mas abre mais rápido da segunda vez! O carregamento das fotos (tanto para abrir como para pré-visualizar a foto em ícone) melhorou consideravelmente!  O VirtualBox também melhorou muito!   Carregamento de vídeos  e pré-visualização deles também melhoraram!

Como também já testei o 2.6.38 aqui, tanto do aptosid como o do Lineduc, posso dizer que a distribuição dos processos realmente melhorou demais no 2.6.38, está melhor que o 2.6.34 Omnislash!  Mas com toda a compilação feita "a mão" para o Buble Bee, ele se mostra mais rápido no geral, só não tem a fluidez que o 2.6.38 tem!


Gunss, quanto ao fstack-protector, o que andei pesquisando é que ele não deve melhorar o desempenho do sistema, mas sim sua segurança! Ele serve para evitar ataques na memória! O interessante é que num documento do linuxfromscratch, ele não recomenda usar "apenas" a opção fstack-protector, existem 3 opções! É como se essa opção fosse a mais fraca em termos de segurança! Também avisa que se usar a opção -03 na compilação, são esperados problemas com programas escritos em Python!

Sabe que eu não lembro de habilitar a opção CONFIG_CC_STACKPROTECTOR no config do kernel!  

Resumindo, se não for para atrapalhar acho que vou deixar essa opção na linha do Makefile!

Então acho que você poderia tentar usar as opções "básicas" da saída do comando cc -march=native -E -v - </dev/null 2>&1 | grep cc1, sem os -mmx e -SSE... da vida! E mantém os native no resto já que você está usando o GCC 4.6 né?

Obs:  Putz, lendo mais aqui da documentação do linuxfromscratch, tería que deixar a opção -D_FORTIFY_SOURCE=2 na linha do make file por conta do fstack-protector! E agora?  

O próximo teste será com o i7!  Vou usar o kernel compilado com as opções acima no Buble Bee no resto da semana para "sentir" mais como ele desempenha!

[Gunss]

@galactus, quando eu perguntei sobre o fstack-protector, eu queria saber se alguem usava e se perdia muito desempenho. Sobre a CONFIG_CC_STACKPROTECTOR aqui eu deixo habiltada, e o kernel do aptosid deixa desabilitado, acho que eles nem usam essa opção na compilação.
Alias, consegui instalar o kernel do aptosid no Lucid. Tive que atualizar o initramfs.

e não sabia que essa opção "-D_FORTIFY_SOURCE=2" deveria entrar no código... Bom saber. Ah, galactus você sabe aonde podemos baixar os patchs, ou então a pasta do linux já com os patchs aplicados do aptosid?
no link onde baixo os .deb vem apenas o kernel linux vanilla.

[vampire_thunder]

Upei o kernel do Lineduc para o servidor. Não divulguei os links aqui, porque não apliquei patch nenhum, com exceção do LZMA e os marchs=native.
Mais detalhes aqui:
http://forum.lineduc.ctics.sigeduc.info/viewtopic.php?f=20&t=393#p521

[galactus]

@galactus, quando eu perguntei sobre o fstack-protector, eu queria saber se alguem usava e se perdia muito desempenho. Sobre a CONFIG_CC_STACKPROTECTOR aqui eu deixo habiltada, e o kernel do aptosid deixa desabilitado, acho que eles nem usam essa opção na compilação.
Alias, consegui instalar o kernel do aptosid no Lucid. Tive que atualizar o initramfs.

e não sabia que essa opção "-D_FORTIFY_SOURCE=2" deveria entrar no código... Bom saber. Ah, galactus você sabe aonde podemos baixar os patchs, ou então a pasta do linux já com os patchs aplicados do aptosid?
no link onde baixo os .deb vem apenas o kernel linux vanilla.

Gunss, eu compilei o Omnislash para o i7 sem o Stack protector e sem o Fortify Source! Não notei diferença nenhuma, já que isso serve para proteger a memória contra ataques mesmo né!

Gunss, acho que o que você quer em relação ao kernel do Aptosid seria isso:

http://aptosid.com/index.php?module=wikula&tag=RecompileAptosidKernel

Aí ele dá os links para baixar o que você precisa!

Buli, tu apagou seu post? Porque?