¿Cómo saber el intervalo de tiempo del progtwigdor de Linux?

Estoy buscando el valor del segmento de tiempo (o quantum) de mi kernel de Linux.

¿Hay un archivo /proc que expone tal información?

(O) ¿Está bien definido en el encabezado de Linux de mis distribuciones?

(O) ¿Hay una función C de la API de Linux (tal vez sysinfo) que expone este valor?

Gracias por adelantado.

El quantum asignado para un proceso en particular puede variar :

Puede sintonizar “slice” ajustando sched_latency_ns y sched_min_granularity_ns , pero tenga en cuenta que “slice” no es un quantum fijo. También tenga en cuenta que las decisiones de preferencia de CFS se basan en el estado instantáneo. Una tarea puede haber recibido un “segmento” completo (variable) de tiempo de CPU, pero la apropiación se activará solo si una tarea más merecedora está disponible, por lo que un “corte” no es el “tiempo de CPU máximo ininterrumpido” que puede esperar ser … pero es algo similar.

Para los procesos en tiempo real con fines especiales que usan SCHED_RR, el horario predeterminado se define en el kernel de Linux como RR_TIMESLICE en include / linux / sched / rt.h.

 /* * default timeslice is 100 msecs (used only for SCHED_RR tasks). * Timeslices get refilled after they expire. */ #define RR_TIMESLICE (100 * HZ / 1000) 

Puede usar sched_rr_get_interval() para obtener el intervalo SCHED_RR para un proceso SCHED_RR específico.

CFS (que es el progtwigdor predeterminado para los procesos) no tiene un intervalo de tiempo fijo, se calcula en tiempo de ejecución en función de la latencia específica ( sysctl_sched_latency ) y el número de procesos en ejecución. Timeslice nunca podría ser menor que la granularidad mínima ( sysctl_sched_min_granularity ).

Timeslice estará siempre entre sysctl_sched_min_granularity y sysctl_sched_latency , que están predeterminados a 0.75 ms y 6 ms respectivamente y se definen en kernel / sched / fair.c.

Pero el tiempo real no se exporta al espacio de usuario.

Existe cierta confusión en la respuesta aceptada entre los procesos SCHED_OTHER (es decir, los que operan en virtud de la política de tiempo compartido de tiempo compartido no en tiempo real no en tiempo real) y los procesos SCHED_RR .

Los archivos sched_latency_ns y sched_min_granularity_ns (que están destinados a la depuración y son visibles solo si el kernel está configurado con CONFIG_SCHED_DEBUG ) afectan la progtwigción de los procesos SCHED_OTHER . Como se señala en la respuesta de Alexey Shmalko, el intervalo de tiempo bajo CFS no es fijo (y no se exporta al espacio del usuario), y dependerá de los parámetros del kernel y factores tales como el buen valor del proceso.

sched_rr_get_interval () devuelve un valor fijo que es el valor cuántico que garantiza la SCHED_RR un proceso SCHED_RR , a menos que sea bloqueado o bloqueado. En Linux tradicional, el quantum SCHED_RR es 0.1 segundos. Desde Linux 3.9, el límite es ajustable a través del archivo /proc/sys/kernel/sched_rr_timeslice_ms , donde el quantum se expresa como un valor de milisegundos cuyo valor predeterminado es 100.

Busqué en Google estas entradas sobre la misma duda de la porción de tiempo de SCHED_RR en Linux. Pero no puedo obtener una respuesta clara tanto de aquí como del código fuente del kernel. Después de más comprobaciones, encontré que el punto clave es “RR_TIMESLICE” es el intervalo de tiempo predeterminado en jiffies , ¡no en milisegundos! Por lo tanto, el intervalo de tiempo predeterminado de SCHED_RR es siempre de 100 ms, sin importar qué HZ haya configurado.

Igual que el valor de “/ proc / sys / kernel / sched_rr_timeslice_ms”, cuyo valor de entrada en milisegundos , pero almacena y muestra en jiffies . Entonces, cuando CONFIG_HZ = 100, encontrará que:

 # echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms # cat /proc/sys/kernel/sched_rr_timeslice_ms 10 

Está un poco confundido Espero que esto te ayude a entenderlo.