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

[Hqxriven]

Então Hqxriven,resolvi recompilar o kernel 4.8.15,aplicando os patchs BFQ,BFK,rt,ck,da uma olhada como ficou,eu acho que não mudou nada no desempenho do pc,minha configuração ;
Intel Celeron CPU G540 @ 2.5GHz,4G memoria dd3, Mesa DRI Intel(R) Sandybridge Desktop

Segue o vídeo >> https://youtu.be/xmsj6KBikvI

Eu acho que está quase lá. Mas ainda sinto que falta algo. Eu testaria sem o RT e usaria uns 300hz sem baixa latência. (só pra ver como ficaria) 

Hqxriven meu velho!  Que bom que ainda acompanha seu tópico! Abraços!

Eu sempre que posso apareço. Só não logo. Gosto muito do Ubuntu.

Grande Abraço!

[overlock_br]

Olá Hqxriven,segui seu palpite recompilei meu kernel mas apenas sem o RT e usando  300hz sem baixa latência,e olha como ficou;

https://youtu.be/yCRFr7GPkO0

Eu acho que ficou melhor que os outros kernels,a resposta foi melhor,o consumo de ram também,processamento também baixo,esta mais fluido mesmo sobre estress o que acham?

Troquei o ambiente gráfico também,instalei o debian stretch com mate.

Estou usando o kernel que vem na distro e notei que o consumo da memoria esta alto,inicia com media de 500MB,e no kernel recompilado inicia em media com 300MB,mas no kernel  compilado bugou o mouse tive que reiniciar usando teclado.

[Hqxriven]

O Galactus como sempre muito preciso nas suas colocações:

Vou até quotar pra vc ler com calma.

Uma coisa que notei logo de cara nos dois vídeos é quanto a variação da frequência do processador.

Note que na versão compilada ele está trabalhando com uma média maior. Pois ele tá procurando te entregar mais coisas logo!  Infelizmente você não usou os mesmos programas nos dois vídeos para comparar melhor.  Tem mais navegadores instalados na versão compilada e na versão do Debian stretch com xfce você abre um vídeo muito rapidamente e depois fecha.

Lembrando que as vezes, em processadores nem tão potentes, usar um kernel que exige demais do processador vai acabar atrasando as coisas e não acelerando.

Eu prefiro quase sempre (exceto em processadores bem tops) uma resposta digamos mais suave no kernel compilado do que algo mais agressivo.

Dessa forma a impressão que passa é que o sistema é mais leve, que ele aguenta de forma mais equilibrada o que é executado e exige menos processamento nas tarefas, ficando mais suave.

O RT e até o Low latency se não forem bem integrados (adequados ao seu processador, sistema de arquivos e demais otimizações) vc acaba percebendo uma aceleração alta na execução do processo vigente mas não há um bom balanço de distribuição de recursos entre todos os processos usados no momento e vc pode sentir uma ligeira piora na performance em geral, vai gerar atrasos. O Galactus foi justamente no ponto.

Se não me engano outros já chegaram nessa conclusão https://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

Agora sobre o mouse fico na dúvida, pode ser desde o driver do mouse que pode ter um patch no kernel padrão, seu mouse ter um problema em kernels recentes, a problemas com hibernação geradas por alterações no kernel compilado ou até problemas na pilha ou porta ou até o mouse mesmo. (aí é de deixar louco mesmo)

Eu lembro de uma vez que a transferência USB ficou ruim (o Galactus percebeu e me deu um toque) e tive que fazer vários testes no kernel pra descobrir a parte do código que era necessária alterar.

Pra casos de baixa otimização (por falta de tempo ou receio mesmo) eu recomendo o teste com o preempt voluntary com 300 Hz com alguns patches. Acho que já está bem melhor agora.

[overlock_br]

Enfim descobri que não foi o mouse e sim o sistema engargalhou,usou 100% da memória e processador,o que sera que pode ter acontecido isso?nos seus testes aconteceu algo assim?
Agora estou tentando compilar o kernel 4.8.15 e esta apresentando o erro de openssl,mas o mesmo ja esta instalado;

Eis o erro;

Código Selecionar Expandir

scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: Arquivo ou diretório não encontrado
#include <openssl/opensslv.h>
                              ^
compilation terminated.
scripts/Makefile.host:107: recipe for target 'scripts/sign-file' failed
make[2]: *** [scripts/sign-file] Error 1
Makefile:562: recipe for target 'scripts' failed
make[1]: *** [scripts] Error 2
make[1]: Leaving directory '/usr/src/linux-source-4.8'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2


[Hqxriven]

Não cheguei a compilar um 4.8 (ainda), e mesmo que compile numa vm não será a mesma coisa.

O máximo que achei foi problemas relacionados a biblioteca de desenvolvimento https://lists.kernelnewbies.org/pipermail/kernelnewbies/2016-July/016488.html

usou 100% da memória e processador,o que sera que pode ter acontecido isso

Pode ser um kernel panic derivado de algum remendo ou de mudanças na linha principal.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566302

Fica difícil uma resposta concreta, mas talvez vc possa chegar na resposta por si próprio.

1 - Primeiro compile um kernel sem patches por uns dois ou três dias e veja se o problema persiste. Se sim vc vai ter que procurar pelo bug mas já vai ter ideia que não foram os patches e outras pessoas devem ter o mesmo problema que vc. Se não parta para o passo 2

2 - Compile adicionando um patch BFQ por exemplo (dê preferência para apenas um patch) e veja se o problema persiste. Se sim vc descobriu um dos culpados. Se não, vá repetindo o processo e usando por alguns dias e assim até ter todas as respostas.

Sempre fiz assim e geralmente achava os culpados.

[overlock_br]

Fiz exatamente isso e foram os patchs então estou compilando sem nenhum patch pra ver se e algo no proprio kernel.
Vichhh,tive outro problema durante a compilação,apresentou o erro  sobre;

Código Selecionar Expandir

CONFIG_SYSTEM_TRUSTED_KEYS
Resolvi da seguinte forma,tem que comentar a linha referente ele no .config,e na hora da compilação ele te informará um key novo só aceitar e continua a compilação normal.

[Hqxriven]

Ao invés de compilar um patch que seja um grupo de patches experimente de um a um.

Exemplo: BFQ, CK, Zen, etc.

Já tive muitos problemas na hora de usar patches agrupados. Algumas vezes ocorre algum problema no agrupamento ou simplesmente há algum problema no código e as vezes até uma simples configuração gera um kernel panic (me lembro bem que tive problemas de suspensão derivados de configuração que geravam isso).

[overlock_br]

Impressionante o poder do linux em geral,testei o slack,arch,sidux,que realmente são distros muito rápidas em geral,mas compilando um kernel pro hardware aplicando os patchs certos,e umas tunagem no sistema fica com desempenho igual até mesmo superior e com as mesmas funcionalidades e praticidade da distro que gosta (no meu caso Debian),eu apenas testei essas distros pela famosa rapidez do sistema,mas são  pobre em praticidade e requer um certo conhecimento avançado,que no final não vale a pena,bom quero dizer que compilando um kernel certo pra maquina se tem um resultado muito bom na distro,eu só queria um sistema rápido e ágil nas execuções e ao mesmo tempo estável,e consegui enfim num hardware ultrapassado,um celerom com 4G ram e vídeo intel onboard.

https://youtu.be/D9wbgVtnxrs

Apliquei os patchs RT,BFQ,CFQ. 

Obs:testando esse kernel dese o dia 4 de Janeiro e nenhum tipo de problema até agora,acho o problema que tive com o kernel anterior que testei foi algum patch que apliquei pois apliquei todos que encontrei,apos muitas tentativas de comiplação cheguei a conclusão que esses que apliquei nesse kernel foi o que melhor se comportou e ficou estável.

[py8elo]

Bom dia mano Hrxriven!!!
Faz tempo que não aprecia por aqui... Mas, hoje resolvi aparecer para saber das novidades e desejar uma feliz páscoa a todos do grupo...
Me conte aí quais são as novidades mano...
Eu estou usando o 16.04 LTS e o hardware ainda é o mesmo...
Nunca mais compilei um kernel... Tenho usado o kernel original da distro mas o desempenho deixa um tanto a desejar...
Se tiver alguma novidade me informe...
Um forte abraço de PY8ELO!!!

Ao invés de compilar um patch que seja um grupo de patches experimente de um a um.

Exemplo: BFQ, CK, Zen, etc.

Já tive muitos problemas na hora de usar patches agrupados. Algumas vezes ocorre algum problema no agrupamento ou simplesmente há algum problema no código e as vezes até uma simples configuração gera um kernel panic (me lembro bem que tive problemas de suspensão derivados de configuração que geravam isso).

[Hqxriven]

Infelizmente estou sem novidades, o estudo tem roubado meu tempo e minhas compilações 

Mas o tutorial ainda pode ser utilizado sem muitas dificuldades (no máximo, uma adaptação). Vc está levemente enferrujado na pior das hipóteses.

Agora além do BFQ, temos atualizações interessantes do BFS e o do MUQSS (sucessor do BFS, que nos poucos testes que fiz achei melhor que o BFS)

Caso use o BFQ tem que ser com EXT3 ou EXT4, com o BTRFS alguns tem relatado perda de dados.

[py8elo]

OK meu caro Riven,
uma coisa estranha que notei foi que o script pra reinstalar o driver Nvidia automáticamente após a instalação de um novo kernel, não tem funcionado e com alguns kerneis não consigo reinstalar o driver nem manualmente.
Vou pesquisar mais um pouco e seguir suas orientações.

[]'s,

Silva.
PY8ELO

Infelizmente estou sem novidades, o estudo tem roubado meu tempo e minhas compilações 

Mas o tutorial ainda pode ser utilizado sem muitas dificuldades (no máximo, uma adaptação). Vc está levemente enferrujado na pior das hipóteses.

Agora além do BFQ, temos atualizações interessantes do BFS e o do MUQSS (sucessor do BFS, que nos poucos testes que fiz achei melhor que o BFS)

Caso use o BFQ tem que ser com EXT3 ou EXT4, com o BTRFS alguns tem relatado perda de dados.

[Hqxriven]

Eu não cheguei a testar, mas lembro de alguns relatos avisando sobre o 4.9 e o driver nvidia legacy. Talvez seja o seu problema.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852152

https://forum.porteus.org/viewtopic.php?f=51&t=6522

https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/4/

https://devtalk.nvidia.com/default/topic/982052/linux/latest-nvidia-driver-340-101-builds-compiles-properly-but-fails-to-load-has-errors-with-linux-kernel-4-9-resolved-with-patch-/

[nando_br]

Meu pc é fraquinho é um Intel celeron G530 com 4G memória,e estou disposto a compilar um kernel otimizado,pesquisei e vi muito conteúdo mas todos antigos,ai pergunto hoje em dia qual patches aplico para ganhar uma performance em meu modesto hardware?

[overlock_br]

Olá,estou com uma dúvida bem incomoda quando compilo o kernel é gerado o nome linux-image-4.16.2-ck11_4.16.2-ck11-10.00.Custom_amd64.deb,como faço para ser gerado com o nome linux-image-4.16.2-ck11.deb apenas?eu estou compilando com o make-kpkg.

[Hqxriven]

Devido aos pedidos e a saudade o omnislash vai voltar, mas agora muito mais profissional, pq poderei investir mais tempo nele.

Estou usando o kubuntu, fiquei muito tempo no slackware e a minha primeira dica pra vcs que usam a versão 20-04 LTS é trocarem o deadline pelo BFQ (Que eu usava no omnislash antigo para fazer ele voar)

Os comandos são bem simples:

cat /sys/block/sda/queue/scheduler

sudo modprobe bfq

cat /sys/block/sda/queue/scheduler

echo "bfq" | sudo tee /sys/block/sda/queue/scheduler

cat /sys/block/sda/queue/scheduler  e vejam se o bfq foi selecionado.

Para reverter troquem o bfq por mq-deadline.

Boa performance para todos vcs.