O comando que você está usando para exibir a carga da CPU está sendo executado em um loop apertado, por isso está competindo com CPUburn. Se você quiser observar a carga da CPU que a CPU teria sem concorrência, adicione algo como sleep 1 no loop.
Em seu teste, inicialmente o loop de observador fica com praticamente todo o CPU, então progressivamente o burnP6 ganha mais e mais compartilhamento de CPU. Essa é uma consequência da política de agendamento do Linux. O kernel do Linux tem um agendador complexo - na verdade, ele tem muitos algoritmos de agendamento e você pode configurar qual (is) usar no tempo de execução. Leia a página man do sched (7) para uma introdução, e a documentação do kernel e a livro de referência, se você quiser entrar em mais detalhes.
Uma pessoa mais experiente do que eu poderia dizer por esta saída qual agendador está ativo em seu sistema. Eu não posso. Eu posso ver que ele privilegia os programas de E / S (o ps | grep loop, que praticamente não faz nada além de carregar executáveis, criar processos e passar dados) em detrimento dos altos consumidores de CPU. Isso faz sentido em muitas situações: o programa intensivo de CPU provavelmente não se importa em gastar 1.1s em vez de 1s em um cálculo, enquanto o programa intensivo de E / S é geralmente um thread de interface de usuário ou um serviço de rede para o qual uma resposta rápida tempo (baixa latência) é apreciado. Existe aparentemente algum tipo de medida de justiça que então empurra a balança para longe do grupo de processos que está monopolizando toda a CPU.
Seria instrutivo brincar com as configurações em /proc/sys/kernel/sched* e ver como o comportamento varia.