Realmente estoy tratando de entender por qué nuestras máquinas virtuales invitadas no usan el controlador de reloj kvm "como se supone que deben hacerlo". Están ejecutando RHEL 7.2, glibc-2.17, kern 3.10.0. Programas como date y perl -e 'print time' obtenga la hora actual, pero hágalo sin hacer una llamada al sistema. Esto se confirma con strace e ltrace y se confirma aún más mediante el uso de gdb y el seguimiento a través del ensamblado que omitió syscall y en su lugar ejecutó una instrucción llamada rtdscp .
¿Es este un intento de optimización por parte de los autores de glibc? ¿Hay alguna forma de deshabilitar esto y obligar a las llamadas glibc a realizar la llamada del sistema (aparte de los trucos LD_PRELOAD)?
ACTUALIZAR 2016-10-14:
Después de revisar el último borrador de POSIX, parte de la respuesta es clara:hay una forma de solicitar el reloj de la CPU, pero GNU glibc ha impuesto esta implementación a sus usuarios por error. La solución es invocar la llamada del sistema directamente. (Booooh)
Si se define _POSIX_CPUTIME, las implementaciones admitirán valores de ID de reloj obtenidos mediante la invocación de clock_getcpuclockid(), que representan el reloj de tiempo de la CPU de un proceso determinado. Las implementaciones también admitirán el valor especial de clockid_t CLOCK_PROCESS_CPUTIME_ID, que representa el reloj de tiempo de la CPU del proceso de llamada al invocar a clock_() o timer_ () funciones.
Dado que el usuario puede ¿Hay algún argumento real en contra de la noción de que si clock_id está establecido en CLOCK_REALTIME , se debe utilizar la llamada al sistema?
Respuesta aceptada:
Creo que la razón por la que no ve que ocurra una llamada al sistema es que algunas llamadas al sistema Linux (especialmente aquellas relacionadas con el tiempo, como gettimeofday(2) y time(2) ) tienen implementaciones especiales a través de vDSO, que contiene implementaciones algo optimizadas de algunas llamadas al sistema:
El "vDSO" (objeto virtual dinámico compartido) es una pequeña biblioteca compartida
que el núcleo asigna automáticamente al espacio de direcciones de todas
aplicaciones de espacio de usuario.
Hay algunas llamadas al sistema que proporciona el kernel
que el código de espacio de usuario termina usando con frecuencia, hasta el punto
de que tales llamadas pueden dominar el rendimiento general. Esto se debe
tanto a la frecuencia de la llamada como a la sobrecarga de cambio de contexto
que resulta de salir del espacio de usuario e ingresar al
kernel.
Ahora, el manual menciona que la información requerida simplemente se coloca en la memoria para que un proceso pueda acceder a ella directamente (después de todo, la hora actual no es un gran secreto). No sé acerca de la implementación exacta, y solo puedo adivinar el papel del contador de marca de tiempo de la CPU en él.
Entonces, no es realmente glibc quien realiza una optimización, sino el kernel. Se puede deshabilitar configurando vdso=0 en la línea de comando del kernel, y debería ser posible compilarlo. Sin embargo, no puedo encontrar si es posible deshabilitarlo en el lado de glibc (al menos sin parchear la biblioteca).
Hay un montón de otra información y fuentes sobre esta pregunta en SE.
Dijiste en la pregunta:
Después de revisar el último borrador de POSIX, parte de la respuesta es clara:hay una forma de solicitar el reloj de la CPU, pero GNU glibc ha impuesto esta implementación a sus usuarios por error.
Lo cual creo que es una declaración bastante audaz. No veo ninguna evidencia de "forzar erróneamente" nada a los usuarios, al menos no en su desventaja. La implementación de vDSO es utilizada por casi todos los procesos de Linux que se ejecutan en los sistemas actuales, lo que significa que si no funcionara correctamente, ya se habrían escuchado algunas quejas muy fuertes. También dijiste que la hora recibida es correcta.
La cita que das del clock_gettime El manual solo parece mencionar que la llamada debe ser compatible con los ID de reloj devueltos por clock_getcpuclockid , nada sobre el comportamiento de CLOCK_REALTIME o gettimeofday .