Por que os utilitários do Linux não usam uma chamada do sistema para obter a hora atual?

Question

Estou realmente tentando entender por que nossas VMs convidadas não estão usando o driver kvm-clock "como deveriam". Eles estão executando o RHEL 7.2, glibc-2.17, kern 3.10.0. Programas como date e perl -e 'print time' obtêm a hora atual, mas fazem isso sem fazer uma chamada do sistema. Isso é confirmado com strace e ltrace e confirmado com o uso do gdb e rastreamento através da montagem que ignorou o syscall e, em vez disso, executou alguma instrução chamada rtdscp .

Esta é uma tentativa de otimização pelos autores da glibc? Existe alguma maneira de desabilitar isso e forçar chamadas glibc para fazer o systemcall (menos de hacks LD_PRELOAD)?

ATUALIZAÇÃO 2016-10-14:

Depois de analisar o último rascunho POSIX , parte da resposta é clara: existe uma maneira de solicitar o relógio da CPU, mas o GNU glibc forçou, de forma errada, essa implementação em seus usuários. A solução alternativa é invocar a chamada do sistema diretamente. (Booooh)

If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the calling process when invoking one of the clock_() or timer_() functions.

Dado que o usuário pode Existe algum argumento real contra a noção de que se clock_id for definido como CLOCK_REALTIME , a chamada do sistema deve ser usada?

    

Answer 1

Eu acho que o motivo pelo qual você não vê um syscall acontecendo, é que algumas chamadas do sistema Linux (especialmente aquelas relacionadas ao tempo, como gettimeofday(2) e time(2) ) têm implementações especiais através do vDSO , que contém implementações um pouco otimizadas de alguns syscalls:

The "vDSO" (virtual dynamic shared object) is a small shared library that the kernel automatically maps into the address space of all user-space applications.

There are some system calls the kernel provides that user-space code ends up using frequently, to the point that such calls can dominate overall performance. This is due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel.

Agora, o manual menciona que as informações necessárias são colocadas na memória para que um processo possa acessá-las diretamente (a hora atual não é muito secreta, afinal de contas). Eu não sei sobre a implementação exata, e só poderia adivinhar sobre o papel do contador de tempo da CPU no mesmo.

Então, não é realmente glibc fazendo uma otimização, mas o kernel. Ele pode ser desabilitado configurando vdso=0 na linha de comando do kernel , e deve ser possível para compilá-lo. Não consigo encontrar se é possível desabilitá-lo no lado da glibc, no entanto (pelo menos sem remendar a biblioteca).

Há várias outras informações e fontes sobre essa pergunta sobre SE .

Você disse na pergunta:

After reviewing the latest POSIX draft, part of the answer is clear: there is a way to request the clock from the CPU, but GNU glibc has wrongly forced this implementation on its users.

Que eu acho que é uma declaração bastante ousada. Eu não vejo nenhuma evidência de "forçar erroneamente" qualquer coisa sobre os usuários, pelo menos não para a sua desvantagem. A implementação do vDSO é usada por quase todos os processos Linux em execução nos sistemas atuais, o que significa que se não funcionasse corretamente, algumas reclamações muito strongs já teriam sido ouvidas. Além disso, você mesmo disse que o tempo recebido está correto.

A cotação que você dá a partir do manual clock_gettime parece apenas mencionar que a chamada deve suportar ids de clock retornados por clock_getcpuclockid , nada sobre o comportamento de CLOCK_REALTIME ou gettimeofday .