só que usando o kernel 2.6.36 o desempenho é o mesmo usando Voluntary ou Low Lantecy. Fantastico o que esses novos patchs juntamente com esse kernel fazem
Interessante... como estou usando mais o 2.6.35 ainda não percebi. Vou colocar uma prioridade RT xo xorg para testar. Valeu pela observação!
os patchs que uso são esses:
Ureadahead
patch -p1 < 0001-trace-add-trace-events-for-open-exec-an.patch
BFQ
patch -p1 < 0001-bfq_iosched-block-prepare_IO_context_code-v1-2.6.36.patch
patch -p1 < 0002-bfq_iosched-block-add-cgroups-kconfig-and-build-bits-for-BFQ-v1-2.6.36.patch
patch -p1 < 0003-bfq_iosched-block-introduce_BFQ-v1-2.6.36.patch
BFS:
patch -p1 < 2.6.36-sched-bfs-357-1.patch
patch -p1 < bfs357-worker_fix.patch
Classic RCU
patch -p1 < rcu_classic.patch
patch -p1 < kernel_rcuclassic.c.diff
patch -p1 < fixes_for_2.6.36.diff
patch -p1 < lib_Kconfig.debug.diff
X com Prio RT e nice -10 e smarter-realtime:
patch -p1 < boost_privileged_tasks-2.6.36-bfs.patch
patch -p1 < smarter_relatime-2.6.33.patch
Selecionei Pentium III durante a compilação. (Não sei pq, acho que cliquei sem querer kkkk)
ps: Por curiosidade repeti o teste com o HandBrake. Como era de se esperar com o sistema em repouso quase não houve diferença entre a velocidade em que o programa realizava o encode.
Mexendo no google-chrome, escutando música e colocando um vídeo no YT o desempenho tendeu para a configuração que tinha o omnislash que funciona em Voluntary. Porém a diferença foi de no máximo 20%, a média é de 10~15%. Cenário completamente diferente utilizando o kernel 2.6.34 + omnislash, onde a diferença era de 60~80%.
Com o kernel 2.6.36 + patchs citados para mim compensa utilizar Preempt Forced + 300hz + Performance.