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:
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:
cc -march=native -E -v - </dev/null 2>&1 | grep cc1
A saída deste comando para o meu Atom 330 foi:
/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"!
![Sorriso forçado ;D](https://ubuntuforum-br.org/Smileys/default/grin.gif)
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!
![Rolar os Olhos ::)](https://ubuntuforum-br.org/Smileys/default/rolleyes.gif)
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!