Eu venho usando o CentOS 5 no VirtualBox já faz um tempo, mas só depois derecompilar o VirtualBox com suporte VBoxHeadless e ficar vendo pelo top se a VM estava no ar é que reparei como era absurda a carga de CPU utilizada, mesmo com VM completamente parada e sem fazer nada. Carreguei uma outra VM com Debian Etch e o uso de CPU era muito mais modesto e com a VM sem fazer nada o uso de CPU ficava em torno de 1 ou 2%, enquanto a VM com o CentOS ficava além dos 80%.

Depois de muito bater cabeça, eis que temos a solução e a explicação.

Existe uma configuração no kernel Linux chamado Hz, de Hertz mesmo, frequência. Basicamente essa frequência determina de quanto em quanto tempo o kernel vai fazer interrupções. Existem prós e contras de se mudar esse valor. Em máquinas lentas ou onde o acesso ao hardware é custoso, por exemplo uma CPU de notebook trabalhando na metade da velocidade pois está fora da tomada e usando a bateria, o ideal é que o kernel só mande interrupções o mínimo necessário. Em máquinas rápidas onde o acesso ao hardware é generoso, quando mais rápido o kernel mandar interrupções, menos tempo uma instrução levará para ser completada.

O kernel do Debian Etch vem configurado com 250Hz e o kernel do CentOS com 1000Hz. Como o CentOS é mais voltado para servidores então faz sentido que ele tenho uma frequêcia de acesso ao hardware muito maior, ou seja, 1000 vezes por segundo. Devido a isso o VirtualBox estava tentando atender às 1000 interrupções por segundo do kernel do CentOS, mesmo ele não fazendo nada.

A velocidade das interrupções tem que ser configurada em tempo de compilação, ou seja uma vez compilado o kernel não dá mais para trocar, tem que compilar de novo. Quer saber quanto está a velocidade de interrupções do seu kernel? Provavelmente no /boot da sua distribuição tem um arquivo chamado config seguido da versão do seu kernel. Dentro dele está toda a configuração utilizada para compilar o seu kernel.

No CentOS 5:

[root@centos5 ~]# cat /boot/config-2.6.18-92.1.1.el5 | grep _HZ
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000

No Debian:

etch:~# cat /boot/config-2.6.22-4-686 | grep _HZ
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250

Mas e agora, tem que recompilar o kernel do CentOS com 250Hz? Felizmente, não. Adicione esses parâmetros mágicos na linha kernel do /boot/grub/menu.list: divider=10 notsc.

title CentOS (2.6.18-92.1.1.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ divider=10 notsc
initrd /boot/initrd-2.6.18-92.1.1.el5.img

O parâmetro divider vai dividir por 10 a velocidade das interrupções (também chamada detick rate) e o parâmetro notsc vai fazer com que o kernel não atualize o relógio pelo clock do hardware, somente pelo tick rate. O porém disso é que o relógio do sistema vai oscilar e não vai ser muito confiável ao longo do tempo. Como estamos falando de um SO virtualizado no VirtualBox e somente para testes, sem problemas. Agora, se você vai utilizar virtualização em um ambiente de produção, aí muda de figura e o ideal é utilizar o Xen. Tanto que o kernel com suporte ao Xen no CentOS tem 250Hz, sendo obviamente um valor mais adequado para um kernel funcionando em um ambiente virtualizado.

Destaco a explanação do desenvolvedor do kernel Robert Love, a respeito dessa questão:

The timer interrupt is at the heart of the system.

Everything lives and dies based on it. Its period is basically the granularity of the system: timers hit on 10ms intervals, timeslices come due at 10ms intervals, etc.

There are important performance reasons for improving it: poll() and select() are timer-based, and you can get better performance by increasing HZ. I believe this was RedHat's rationale.

There are also process response (i.e. latency) benefits. One good example would be process preemption: consider a process with 81ms remaining of its timeslice. It runs for 80ms, and now it has 1ms left. The timer interrupt hits. Now it continues running. In 1ms, it should be preempted, but it will continue running for 10ms, until the next timer interrupt hits.

...

There are downsides, however. The major one is the increased timer overhead. Going from HZ=100 to HZ=1000 you have 10x more timer interrupts and thus 10x overhead. Now, on a fast system, timer overhead is probably negligible to begin with. Ten times nothing is still nothing. But on a slower system (by slow I mean 386 or 486 slow) it may be an issue.

A tendência é que o kernel Linux não seja conduzido por uma frequência constante, mas sim que ele se adapte conforme a necessidade de processamento. A esse recurso damos o nome de kernel tickless, que está disponível a partir da versão 2.6.21 e vem sendo melhorado. Repare que na configuração do kernel no Debian Etch mostrada acima, o parâmetro CONFIG_NO_HZ está habilitado. Isso quer dizer que, quando o kernel ficar parado, ele vai ficar parado mesmo. Mas quando precisar executar alguma tarefa, ele vai trabalhar a 250Hz.

Para saber mais:
Linux: 2.6.21-rc1, Dynticks Merged
CentOS 5.1 guide for VMware Fusion
Linux Kernel Configuration - notsc
Feature: Robert Love Explains Variable HZ