Sou o autor do post do blog linkado pelo fã do ubuntu: link
Essa postagem no blog não apresenta nenhum fato, é apenas teoria . É assim que funciona: o processador "pára" com mais frequência para ver se há alguns processos que exigem atenção imediata. Isso significa que esses processos serão executados antes dos outros, então você não irá pular quadros ao codificar, ou terá grandes atrasos entre os cliques do mouse e as mortes do inimigo. Isso não significa que todos os processos terminarão mais cedo: na verdade, a CPU está perdendo uma parte maior de seu tempo decidindo qual processo será executado a seguir e fazendo a troca de contexto. Portanto, o tempo total de execução é maior, e é por isso que ninguém executa um kernel preemptiva em servidores web ou em bancos de dados. Mas um kernel preemptível de 300Hz (ou mesmo 1000Hz) é o melhor para servidores de jogos.
Mas hoje em dia os processadores têm muitos núcleos, por isso, quando há poucos processos que requerem atenção, eles podem ser facilmente alocados em um núcleo diferente, em vez de esperar que um núcleo o aceite.
(o stackexchange requer referências / experiência pessoal: sou engenheiro eletrônico, noobgamer sedento de sangue mantendo vários servidores no link ).
Então, como regra geral, eu diria: se o seu processador é um poderoso quad-core de alta freqüência e você normalmente não abre muitas páginas enquanto codifica / decodifica / joga (huh) , você poderia apenas tentar o kernel genérico (ou i686, ou amd64 se existirem) e ter o maior throughput possível (isto é, o processamento crúco de números que o processador é capaz de fazer). Se você tiver problemas (eles realmente devem ser menores) ou sua máquina é um pouco menos poderosa do que o topo do mercado, vá para o pré-pagamento.
Se você estiver em uma máquina de baixo custo que tenha apenas um ou dois núcleos, tente a -lowlatency. Você também pode tentar o tempo-real, mas descobrirá que ele tende a bloquear processos até que os "em tempo real" terminem seu trabalho. Eu acredito que o kernel em tempo real não é o "vanilla", mas tem o patch CONFIG_PREEMPT_RT aplicado. Eu acho que os kernels em tempo real são apenas para aqueles que têm que construir um único aplicativo em sistemas embarcados, então usuais usuários de desktop não devem ter benefícios reais, porque eles geralmente executam um bom número de aplicativos ao mesmo tempo.
Finalmente, as opções mais relevantes do kernel, se você quiser recompilar seu kernel para ter uma área de trabalho de baixa latência, são:
PREEMPT=y
e:
CONFIG_1000_HZ=y
Para adicionar um pouco de economia de energia, você pode verificar esta:
CONFIG_NO_HZ=y