hi es el tiempo empleado en procesar interrupciones de hardware. Las interrupciones de hardware son generadas por dispositivos de hardware (tarjetas de red, controlador de teclado, temporizador externo, sensores de hardware, ...) cuando necesitan señalar algo a la CPU (por ejemplo, han llegado datos).
Dado que esto puede suceder con mucha frecuencia, y dado que básicamente bloquean la CPU actual mientras se ejecutan, los controladores de interrupción de hardware del kernel están escritos para ser lo más rápidos y simples posible.
Si es necesario realizar un procesamiento largo o complejo, estas tareas se difieren mediante un mecanismo llamado softirqs . Estos se programan de forma independiente, pueden ejecutarse en cualquier CPU, incluso pueden ejecutarse simultáneamente (nada de eso es cierto para los controladores de interrupciones de hardware).
La parte sobre las IRQ duras que bloquean la CPU actual y la parte sobre softirqs poder ejecutarse en cualquier lugar no es exactamente correcto, puede haber limitaciones y algunas IRQ duras pueden interrumpir a otras.
Como ejemplo, una interrupción de hardware de "datos recibidos" de una tarjeta de red podría simplemente almacenar la información "la tarjeta ethX necesita servicio" en algún lugar y programar un softirq . El softirq sería lo que activa el enrutamiento real del paquete.
si representa el tiempo dedicado a estos softirqs .
Una buena lectura sobre el softirq El mecanismo (con un poco de historia también) es I'll Do It Later:Softirqs, Tasklets, Bottom Mitades, Task Queues, Work Queues and Timers de Matthew Wilcox (PDF, 64k).
st , "robar tiempo", solo es relevante en entornos virtualizados. Representa el momento en que la CPU real no estaba disponible para la máquina virtual actual:el hipervisor la "robó" de esa VM (ya sea para ejecutar otra VM o para sus propias necesidades).
El documento de contabilidad del tiempo de CPU de IBM tiene más información sobre el tiempo de robo y la contabilidad de CPU en entornos virtualizados. (Está dirigido a hardware tipo zSeries, pero la idea general es la misma para la mayoría de las plataformas).
- us - Tiempo pasado en el espacio del usuario
- sy - Tiempo pasado en el espacio del kernel
- ni:tiempo dedicado a ejecutar procesos de usuario agradables (prioridad definida por el usuario)
- id - Tiempo invertido en operaciones inactivas
- wa:tiempo de espera en los periféricos IO (por ejemplo, disco)
- hola:tiempo dedicado al manejo de rutinas de interrupción de hardware. (Cada vez que una unidad periférica quiere atención de la CPU, literalmente tira de una línea, para indicarle a la CPU que la atienda)
- si:tiempo dedicado al manejo de rutinas de interrupción de software. (un fragmento de código, llama a una rutina de interrupción...)
- st:tiempo invertido en esperas involuntarias por parte de la CPU virtual mientras el hipervisor da servicio a otro procesador (robado de una máquina virtual)
El valor "st" se puede explicar simplemente usando una instancia T2.micro EC2 de AWS.
En la documentación de AWS, puede leer que solo obtiene un rendimiento de referencia del 10 % por VCPU. Esto significa que si tiene un proceso que consumiría mucho tiempo de CPU, el valor "st" permanecerá alrededor de 90 ya que solo puede usar el 10% de la VCPU. La suma de los otros valores se mantendrá alrededor de 10.
Entonces, AWS está usando el hipervisor para permitirle acceder solo a una cierta cantidad de poder de cómputo. Lo ralentiza intencionalmente, ya que solo está utilizando un tipo de instancia de bajo nivel.
Espero que esto haga las cosas un poco más fáciles de entender.