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

[dtomadon]

Beleza galera!
Sem querer atrvessar mas atravessando, tem alguem usando o 10.10 com omnislash ou terei que ficar preso no 10.04?
Será que dá para usar o kernel .34 + omni 1.4.4 com ganho de performance no meerkat? Gostaria de alguma sugestão se possível.
Abraçõs.

Como pode ver na minha assinatura , uso o Kubuntu 10.10 com o omnislash 1.4.4 que usa o kernel 2.6.34 + patch do Ureheadahead , tirando o boot que achei mais lento que o kernel nativo do meerkat , o restante está ótimo !!!

[Niller]

Legal  legal!
Vou mexer com isso hoje à tarde! Agora aproveitando, alguém está sofrendo com o video
Intel 945? Eu notei uma queda de desempenho do 10.10 em relação ao 10.04.

[Gunss]

eu não vou usar a versão 10.10.

Com o kernel omnislash acho que ninguém vem tendo problemas com vídeo intel e nvidia não

[buli]

Impressões sobre 2.6.34.7 + BFS v0.357

Primeiro vou descrever o tipo de teste que faço. É uma coisa bem simples. Como um outro usuário já disse, somente fico usando o sistema, do seguinte jeito:

Teste simples:

1. Abro um vídeo no youtube. Pode ser qualquer um, mas sempre o mesmo.
2. Depois abro um arquivo de imagem grande, 60 MB, em formato .tif

Como trabalho em micros um tanto fracos, Pentium 4 com RAM de 512 MB, isso ai já é suficiente para deixar os sistema sobrecarregado: Enquanto a imagem .tif abre, quase toda a memoria física (~485 MB) é consumida e fica fazendo swap adoidado.

As vezes abro o arquivo de vídeo localmente, para o teste não depender da rede, mas o arquivo .flv é exatamente o mesmo. Os resultados também diferem muito pouco em cada um desses casos (local ou youtube).

Teste mais "completo":

Igual que o teste simples acima, mas antes deixo o sistema no limite da capacidade de threads que podem ser processados em paralelo, por exemplo, compilando o kernel com make -j2 ou com CONCURRENCY_LEVEL=2 no make-kpkg no Debian.

NOTA: O Pentium 4 que uso tem HT, por isso uso 2 threads.

Como "interpreto" os resultado do teste: Cada rodada de testes começa com o micro reiniciando de zero.

Enumero o comportamento do sistema desde o melhor caso até o pior caso possível:

1. O sistema funciona bem bem durante o tempo que dura o teste.
2.  O sistema funciona bem, mas os aplicativos em geral demoram um pouco para abrir.
3. A imagem no vídeo da pequenas congeladas, em quanto a imagem de 60 MB abre. Depois o vídeo fica normal. O som do vídeo funciona bem o tempo todo.
4. No vídeo a image congela e o som pula ligeiramente.
5. No vídeo a imagem desaparece (fica a tela branca) e som pula por intervalos longos.
6. Quase tudo para enquanto a imagem de 60 MB abre. Depois continua a funcionar bem.
7. O sistema trava. Somente volta depois de um tempo. Alguns aplicativos são fechados.
8. O sistema trava de vez. O micro deve ser reiniciado.

Até 3 considero um resultado aceitável, ou 4 se for o teste completo. Porém, inclusive com o teste simples, já vi todos esses casos acontecerem.

Patches que estou usando:: CK2 e BFS v0.357

Acho que o patch CK poderia ser resumido como: Swapping agressivo. No caso do meu micro isso é bom, exceto por uma única coisa: Na última versão foi acrescido um patch que faz dirty_ratio=5. Com isso o resultado do teste fica entre 6 e 8, ou seja, em não poucos casos, o sistema chega a travar de vez. Por isso, sempre volto ao valor default que é 20.

Com o BFS 318 o resultado do teste ficava entre 1 e 4. No 357 piorou um pouco, chegando até 5 ou 6.

Especulação: Fuçando um pouco no código, vi que entre as coisas que foram mudadas no BFS 357 tem duas variáveis:

1. RESCHED_US: Antes era 1 e passou para 100.

Esta variável controla o timeslice dos threads. Na prática, o valor 100 faz que um thread com menos de 100 microsegundos no seu timeslice seja rescalado (rescheduled). Ou seja, um thread com menos de 100 us no timeslice é considerado com um thread com 0 us de timeslice. (Timeslice seria o tempo que um dado thread é colocado para rodar no CPU).

2. prio_ratios: antes era 100 e passou para 128. Essa variável também intervém no cálculo do timeslice. Mas neste caso, não parece ser uma mudança muito grande.

Eu voltei o valor dessas variáveis para os valores anteriores, ou seja 1 e 100 respectivamente, e isso tem feito o teste voltar para 4, diria que em 50% dos casos.

Enfim, foi isso que fiz por enquanto. Vou continuar testando.

[Gunss]

@buli

o valor da RESCHED_US ser 100 no BFS 0.357 é ruim pois ou você tem um processador bom ou então esta lascado. É isso?

[Hqxriven]

Depois do post com a análise do buli... 

Eu já estava confuso pensando em como ia abordar o assunto de forma simples e vc já chegou fazendo bonito.

Ótimo post!! Obrigado buli!!

-------------------------------------------

Vou falar um pouco também...

O que achei foi que o 3.18 (no omnislash padrão) é mais lento que o 3.57. O 3.57 a latência é mais baixa, mas a prioridade da "cache" (buffer) não tem tanta importância e sim a velocidade que o processador acessa a informação.

No sistema "virtual de memória" do linux que compreende o buffer, a swap, o tempo que o dado fica "sujo" e quando é limpo na cache do hd e as páginas de memória (basicamente é isso, mas tem alguns sistemas de proteção) percebi que no 3.57 diferente do 3.18 o comportamento é o oposto.

Basicamente ele está diminuindo o tamanho da cache para que a informação por ter um volume menor seja passada mais rapidamente para o processador que ira processá-la. Teoricamente seria mais rápido se os HDs e os processadores fossem muito mais rápidos!!

O problema é quando existem novas informações que entram na fila para serem processadas e o hd e o processador estão ocupados e a cache está com dados que não foram limpos para a entrada de um novo dado. Isto é, volume agressivo de dados na cache entrando e saindo.

Sabe o que resulta isso: os resultados 6 a 8 do teste do buli!!

Vc precisa de um kernel equilibrado para que o processador, hd e memória ram trabalhem da melhor forma possível foi justamente por isso que o 1.4.4 não usou o CK (percebi que ele retirou o equilíbrio das páginas de memória)

Resumindo:

Acho que nesse ponto a dupla BFS 3.18 + BFQ consegue gerenciar bem as requisições mesmo com um grande volume de dados se o usuário tem um processador, um hd e uma memória razoáveis, coisa que não ocorre com o 3.57 que deixa o sistema desbalanceado com mais facilidade, por não conseguir aproveitar de forma eficiente os recursos.

-----------

Galera ainda estou tentando achar uma solução estável para o 3.57 para deixá-lo equilibrado. Vou demorar mas estou confiante que iremos conseguir!!

[hiltongil]

Depois do post com a análise do buli... 

Eu já estava confuso pensando em como ia abordar o assunto de forma simples e vc já chegou fazendo bonito.

Ótimo post!! Obrigado buli!!

-------------------------------------------

Vou falar um pouco também...

O que achei foi que o 3.18 (no omnislash padrão) é mais lento que o 3.57. O 3.57 a latência é mais baixa, mas a prioridade da "cache" (buffer) não tem tanta importância e sim a velocidade que o processador acessa a informação.

No sistema "virtual de memória" do linux que compreende o buffer, a swap, o tempo que o dado fica "sujo" e quando é limpo na cache do hd e as páginas de memória (basicamente é isso, mas tem alguns sistemas de proteção) percebi que no 3.57 diferente do 3.18 o comportamento é o oposto.

Basicamente ele está diminuindo o tamanho da cache para que a informação por ter um volume menor seja passada mais rapidamente para o processador que ira processá-la. Teoricamente seria mais rápido se os HDs e os processadores fossem muito mais rápidos!!

O problema é quando existem novas informações que entram na fila para serem processadas e o hd e o processador estão ocupados e a cache está com dados que não foram limpos para a entrada de um novo dado. Isto é, volume agressivo de dados na cache entrando e saindo.

Sabe o que resulta isso: os resultados 6 a 8 do teste do buli!!

Vc precisa de um kernel equilibrado para que o processador, hd e memória ram trabalhem da melhor forma possível foi justamente por isso que o 1.4.4 não usou o CK (percebi que ele retirou o equilíbrio das páginas de memória)

Resumindo:

Acho que nesse ponto a dupla BFS 3.18 + BFQ consegue gerenciar bem as requisições mesmo com um grande volume de dados se o usuário tem um processador, um hd e uma memória razoáveis, coisa que não ocorre com o 3.57 que deixa o sistema desbalanceado com mais facilidade, por não conseguir aproveitar de forma eficiente os recursos.

-----------

Galera ainda estou tentando achar uma solução estável para o 3.57 para deixá-lo equilibrado. Vou demorar mas estou confiante que iremos conseguir!!

Ai HQ, já viu essa notícia (http://br-linux.org/2010/o-patch-de-200-linhas-que-multiplica-o-desempenho-no-linux/) sabe de algo referente a isso?

[Hqxriven]

Ai HQ, já viu essa notícia (http://br-linux.org/2010/o-patch-de-200-linhas-que-multiplica-o-desempenho-no-linux/) sabe de algo referente a isso?

Interessante...

Aposto que o CK vai analisar isso e vai atualizar o BFS.

[Gunss]

nossa...

Eu voltei para o BFS do omnislash original. Percebi que ao comprimir arquivos o sistema fica inútil.

Puxei bastante do PC esses dias e ele não respondeu. O tempo para editar vídeos aumentou, enfim, realmente no quesito estabilidade e até mesmo desempenho melhor ficar com o omnislash, agora se você tiver um i7 com memória DDR3 a 1600Mhz + SSD, FAÇA A FESTA! 

[hiltongil]

Ai HQ, já viu essa notícia (http://br-linux.org/2010/o-patch-de-200-linhas-que-multiplica-o-desempenho-no-linux/) sabe de algo referente a isso?

Interessante...

Aposto que o CK vai analisar isso e vai atualizar o BFS.

Até procurei mais informações acerca da noticia mas não encontrei muita coisa, mas até o final dessa semana deve sair mais alguma coisa com explicações mais completas.

[Gunss]

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

o pessoal do phoronix testou o patch. Usando o PC com uma compilação -j64.


ps: esqueci de comentar que com o BFS 3.57 zipando 3 arquivos ao mesmo tempo o load average chegou a marcar 7.37
vou testar com o BFS 3.18 jajá. 

[buli]

Até procurei mais informações acerca da noticia mas não encontrei muita coisa, mas até o final dessa semana deve sair mais alguma coisa com explicações mais completas.

Acho que esse aqui é o link para o patch:

http://marc.info/?l=linux-kernel&m=128978361700898&w=2

Pelo que vi, parece que funciona no CFS.

[hiltongil]

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

o pessoal do phoronix testou o patch. Usando o PC com uma compilação -j64.


ps: esqueci de comentar que com o BFS 3.57 zipando 3 arquivos ao mesmo tempo o load average chegou a marcar 7.37
vou testar com o BFS 3.18 jajá. 

Pois é, até cheguei a ver o site da Phoronix, o link do brlinux apontava para lá. Mas tava a procura de uma informação mais "mastigada" para leigos (no caso, eu  )

[vampire_thunder]

Compilei esse novo patch com o Kernel 2.6.37, do natty, e sinceramente não percebi nenhuma diferença.

[Gunss]

Compilei esse novo patch com o Kernel 2.6.37, do natty, e sinceramente não percebi nenhuma diferença.

tenta compilar com o vanilla. o pessoal do phoronix compilou com o vanilla