Bem, antes de tudo, o kernel escolhe o melhor automaticamente, geralmente é o TSC se estiver disponível, porque é mantido pelo cpu e é muito rápido (RDTSC e leitura do EDX: EAX).
Mas esse não foi sempre o caso, nos primeiros dias, quando os sistemas SMP eram construídos principalmente com vários cpus discretos, era muito importante que o cpus fosse tão "igual" quanto possível (combinação perfeita de modelo, velocidade e stepping), mas mesmo assim algumas vezes ocorreu que era visualmente mais rápido que o outro, então o contador TSC entre então era "instável", essa era a razão para permitir a mudança (ou desativá-lo com o parâmetro "notsc" do kernel ). E mesmo com estas restrições o TSC ainda é a melhor fonte, mas o kernel tem que tomar muito cuidado para confiar apenas em um cpu em sistemas multicore ou tentar ativamente mantê-los sincronizados, e também levar em conta coisas como suspender / resumir redefine o contador) e a escala de frequência da CPU (afeta o TSC em alguns modelos de CPU).
Algumas pessoas naqueles primeiros dias do SMP até construíram sistemas com CPUs de diferentes velocidades (tipo a nova arquitetura BIG.little in arm), que criaram grandes problemas na área de cronometragem.
Como uma forma de verificar as resoluções que você tem clock_getres () e você tem um exemplo aqui .
E um par de links extras: documento oficial do kernel (há outros arquivos interessantes em este dir) e ressincronização do TSC em Chromebooks com alguns benchmarks de diferentes clocksources .
Em suma, não deve haver nenhuma alteração visível no espaço do usuário ao alterar a fonte de clocks, mas apenas um gettimeofday () .