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.
