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

[Gunss]

Bem, aqui eu uso o 300 hz e agora estou testando o preempt. No Zen fica ruim, porém com os patchs que o HQ e o buli passaram, até agora ta blz. Sim, uso efeitos compiz (poucos mas uso). Eu não uso mais o Folding Home, infelizmente meu quarto é muito quente, e eu não uso um sistema 64bit para usar o cliente SMP. A parte gráfica fica por conta da Intel (lixo), o sistema de arquivos, por enquanto não uso nenhum tweak. Sei que o vídeo intel e o sistema de arquivos "acabam" com o sistema. Mas com mais simplicidade temos melhor objetivo. Usando poucos patchs no omnislash consigo usar o sistema com preempt, porém com as zilhões de tweaks do zen o sistema não aguenta.

Me manda teu email por MP que eu te passo.

Você mesmo já explica tudo Gunss!  Você não ataca em dois dos principais pontos que deixam uma máquina lenta!  E em se tratando de Linux isso é ainda mais crítico!  Que são o sistema de arquivos e a parte gráfica!  Intel com efeitos do compiz.... Você é um herói!

O Zen tem configurações bastante agressivas, seu processador resiste a elas, o negócio é quando ele tem que transformar esses processos em ações no disco rígido e na parte gráfica! Aí tá o gargalo! Já teve oportunidade de usar um vídeo Onboard da Intel no Windows?  É uma mudança da água para o vinho! O meu Atom responde muito melhor a parte gráfica no Windows do que no Linux!  

O folding home é um colosso, um caminhão de processos!  Só com configurações tipo garçom pra isso funcionar direito!

Por incrível que pareça, aqui até a versão 9.04 a diferença entre o Windows e Linux na parte gráfica era enorme. Porém usando o 10.04 a diferença caiu bastante.
Eu acho o ext4 bem responsável. Não acho que perca em desempenho para o NTFS do windows não.

Quanto o F@H, com o sistema bem balanceado você nem senti ele, o nice dele é 19.

recebeu o email?

[galactus]

Bem, aqui eu uso o 300 hz e agora estou testando o preempt. No Zen fica ruim, porém com os patchs que o HQ e o buli passaram, até agora ta blz. Sim, uso efeitos compiz (poucos mas uso). Eu não uso mais o Folding Home, infelizmente meu quarto é muito quente, e eu não uso um sistema 64bit para usar o cliente SMP. A parte gráfica fica por conta da Intel (lixo), o sistema de arquivos, por enquanto não uso nenhum tweak. Sei que o vídeo intel e o sistema de arquivos "acabam" com o sistema. Mas com mais simplicidade temos melhor objetivo. Usando poucos patchs no omnislash consigo usar o sistema com preempt, porém com as zilhões de tweaks do zen o sistema não aguenta.

Me manda teu email por MP que eu te passo.

Você mesmo já explica tudo Gunss!  Você não ataca em dois dos principais pontos que deixam uma máquina lenta!  E em se tratando de Linux isso é ainda mais crítico!  Que são o sistema de arquivos e a parte gráfica!  Intel com efeitos do compiz.... Você é um herói!

O Zen tem configurações bastante agressivas, seu processador resiste a elas, o negócio é quando ele tem que transformar esses processos em ações no disco rígido e na parte gráfica! Aí tá o gargalo! Já teve oportunidade de usar um vídeo Onboard da Intel no Windows?  É uma mudança da água para o vinho! O meu Atom responde muito melhor a parte gráfica no Windows do que no Linux!  

O folding home é um colosso, um caminhão de processos!  Só com configurações tipo garçom pra isso funcionar direito!

Por incrível que pareça, aqui até a versão 9.04 a diferença entre o Windows e Linux na parte gráfica era enorme. Porém usando o 10.04 a diferença caiu bastante.
Eu acho o ext4 bem responsável. Não acho que perca em desempenho para o NTFS do windows não.

Quanto o F@H, com o sistema bem balanceado você nem senti ele, o nice dele é 19.

recebeu o email?

Recebi sim o e-mail!  Positivo mas ainda não operante!

Quando chegar em casa eu vou testar!

[Alyscom]

Oi, eu compilei o kernel omnislash agora a pouco para o pc de um amigo meu, bom... resolvi upar eles para quem quiser!
esta configurado desta forma: Low-latency, 1000Mhz, performance e em processador P4!
Apliquei o patch ureadahead também!

linux-headers-2.6.34-omnislash1.4.4_x86_i386.deb
linux-image-2.6.34-omnislash1.4.4_x86_i386.deb

[Gordin]

Não testei isso, mas algum de vcs já leu e anima testar?
 http://www.phoronix.com/scan.php?page=article&item=linux_transparent_hugepages&num=1

[cesargcomp]

Instalei o kernel kernel liquorix (se não me engano do sidux) no meu Lucid (10.04) através de um repositório do Debian Squeeze e ficou "tinindo". O kernel é o 2.6.36.2. Tá super-rápido e olha que usava o omnislash. Meu Athlon XP 2600+ com 1 GB tá respondendo quase que de imediato. O consumo de memória é praticamente o mesmo mas responde melhor. Eu tentei compilar o kernel liquorix mas após quase 3 horas de compilação, "panic". Se alguém quiser se aventurar e passar a "receita".

Patches: http://liquorix.net/sources/
Config: http://liquorix.net/sources/36/config.i386 ou http://liquorix.net/sources/36/config.amd64
Sources e debs: http://liquorix.net/debian/pool/main/l/linux-liquorix-2.6/

Fiz assim:
Adicionei o repositório do Debian Squeeze:

Código: [Selecionar]

echo deb http://liquorix.net/debian sid main > liquorix.list
sudo mv liquorix.list /etc/apt/sources.list.d/
sudo apt-get updateAdicionei as chaves:

Código: [Selecionar]

sudo apt-get install liquorix-archive-keyring liquorix-keyring liquorix-keyrings
sudo apt-get updateBaixei e instalei o libncurses5 do Debian Squeeze:

Código: [Selecionar]

wget http://ftp.br.debian.org/debian/pool/main/n/ncurses/libncurses5_5.7+20100313-4_i386.deb
sudo dpkg -i libncurses5_5.7+20100313-4_i386.deb
sudo apt-get -f installInstalei o kernel liquorix:

Código: [Selecionar]

sudo apt-get install linux-headers-2.6.36-2.dmz.4-liquorix-686 linux-image-2.6.36-2.dmz.4-liquorix-686 linux-image-2.6-liquorix-686 linux-headers-2.6-liquorix-686
:p

[Gunss]

engraçado, aqui estou usando o 2.6.36 normalmente sem atualizar o libncurses.

Vou testar a dica cesargcomp, valeu

[4d4c47]

engraçado, aqui estou usando o 2.6.36 normalmente sem atualizar o libncurses.

Vou testar a dica cesargcomp, valeu

também estou usando o 2.6.36 no ubuntu 10.04 sem precisar atualizar o libncurses, não vejo necessidade de atualizar-la não, isso vai como uma dica.

[cesargcomp]

engraçado, aqui estou usando o 2.6.36 normalmente sem atualizar o libncurses.

Vou testar a dica cesargcomp, valeu

também estou usando o 2.6.36 no ubuntu 10.04 sem precisar atualizar o libncurses, não vejo necessidade de atualizar-la não, isso vai como uma dica.

No meu caso foi solicitado que atualizasse.

[hamadecd]

Cara você disse que no Kubuntu a opção timer frequency tava tanto, enfim eu uso o Ubuntu 10.10 e como que eu faço pra ver essa informação porque fiquei super curioso

[Andreson Goveia]

engraçado, aqui estou usando o 2.6.36 normalmente sem atualizar o libncurses.

Vou testar a dica cesargcomp, valeu

também estou usando o 2.6.36 no ubuntu 10.04 sem precisar atualizar o libncurses, não vejo necessidade de atualizar-la não, isso vai como uma dica.

No meu caso foi solicitado que atualizasse.

Aqui reclamou do libncursesw ai instalei e foi, legal, estou instalando para testar vamos ver.

[buli]

Para que está experimentando com o 2.6.36:

Tem um novo patch no mainline do kernel.org: http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.36.2.bz2

Tem também uma nova versão do BFS: http://ck.kolivas.org/patches/bfs/2.6.36/2.6.36-sched-bfs-360.patch

Kolivas tem um blog aqui http://ck-hack.blogspot.com/ e na última entrada, de 14/12/2010, tem comentários sobre a nova versão. Parece que processadores com modo "turbo", tipo Intel i*, poderiam agora tirar algum ganho extra em vazão (throughput) . Aqui tem um trecho do changelog:

Change the locality logic to try to reschedule on the exact same logical core
instead of assuming scheduling on a sibling core or sibling thread is
equivalent. This allows CPUs with a "turbo" mode (such as i7) to use that more
often by using one CPU more than spreading out, and allows ondemand cpu
frequency scaling to ramp up more easily when a task stays on the same CPU. It
increases throughput on threaded CPUs when lightly loaded, and may offer both
performance and power saving advantages on all SMP topologies with cpu
frequency scaling.

Eu fiz uma compilada rápida para testar e todos os outros patches e recursos básicos funcionam bem. Não precisei modificar nada.

Somente não testei os recursos mais "avanzados" como aufs e squashfs + lzma. Mas já tinha testado no 36.1 com BFS v0.357 e todo funcionava bem.

[Gunss]

Vou testar, não gosto de usar o modo performance, prefiro o ondemand.
Valeu pela dica.

[galactus]

Nossa os comentários do Kolivas sobre o BFS 360 são incríveis! Ele volta a dizer que não precisa do cgroups, e tem até o tempo em que nós usuários começamos a perceber diferença no tempo de latência do sistema!  Segundo ele, as "regulagens" dessa versão não são arbitrárias, mas do que ele constatou em relação a nossa percepção de latência!  Segundo ele, a partir de 7 milisegundos nós percebemos diferenças!

Eu testei primeiro uma versão binária do  kernel 2.6.36 com BFS do Blog famoso do cgroups, lá o camarada diz que esta versão teria o mesmo efeito se você usar o cgroups. Ficou uma derma só! Muito mais lento que a versão que eu compilei do Omnislash 1.4.4 aqui para o meu PC de casa!

Ainda não tive tempo de testar essas versões do 2.6.36 vanilla!  São muitos patchs, não sei se é mais fácil fazer com o cesargcomp sugere, baixar logo o kernel do Liquorix e testar!  Vou ter que acabar comprando outro pau veio para testes!  A dona encrenca invoca muito se o sistema vai pro brejo com esses kerneis experimentais! Ela fica sem internet até eu poder arrumar tudo de novo!  É soda!

[Gunss]

ue, galactus, os patchs que te passei não tem mistério. Foi bem rápido fazer funcionar.
Vou dar uma lida melhor sobre esse novo BFS pra vê se vale a pena atualizar.

[galactus]

ue, galactus, os patchs que te passei não tem mistério. Foi bem rápido fazer funcionar.
Vou dar uma lida melhor sobre esse novo BFS pra vê se vale a pena atualizar.

Não Gunss, só to dizendo que não deu pra testar! Ainda vou compilar o 2.6.36 com aqueles patchs que você passou!