¿Cuáles son los efectos, si los hay, de las prioridades y políticas del planificador para subprocesos en un cpuset no supervisado?

Tengo un sistema Linux en el que hemos usado cgroups para crear dos cpusets exclusivos de cpu, A y B, y donde hemos migrado todos los hilos de usuario y todos los hilos de kernel no enlazados a un cgroup conectado a cpuset A. Las cosas que se ejecutan en cpuset A tienen políticas de planificador variables y prioridades variables, y hay muchos más subprocesos ejecutándose en cpuset A que núcleos en cpuset A.

También hay un pequeño número de procesos muy activos asociados a cpuset B, donde el número total de subprocesos de usuario en estos procesos nunca es mayor que el número de núcleos disponibles exclusivamente en cpuset B. El objetivo es proteger estas tareas importantes que se ejecutan en cpuset B de otra actividad en la máquina y para minimizar la latencia de procesamiento.

En tal configuración, ¿la política / prioridad de programación de los hilos de usuario que se ejecutan en cpuset B tiene algún efecto observable? Dicho de otra manera: ¿cambiar las políticas de programación de los subprocesos B cpuset de SCHED_OTHER por defecto a SCHED_FIFO o SCHED_RR tendría alguna consecuencia, buena o mala?

Parece que la respuesta debería ser 'no', ya que el planificador debería poder asignar a cada hilo que se ejecuta en cpuset B su propio núcleo dedicado, por lo que no habría nada que priorizar o programar, por lo que la política y la prioridad relativa de B Los hilos cpuset no importarían. Por otro lado, hay que preocuparse por los hilos del núcleo vinculados y los aspectos del 'dominio del planificador', y probablemente otras cosas que no he considerado.

¿Las políticas y prioridades de programación de subprocesos que se ejecutan en un cpuset exclusivo sobreaprovisionado importan en algún sentido práctico?

El intervalo de tiempo utilizado será importante para los trabajos intensivos de CPU que requieren persistencia de caché, a menos que bloquee un núcleo particular a cada PID. Puede aumentar el intervalo de tiempo con la política del planificador SCHED_BATCH y mejorar el rendimiento hasta un 300% en algunos casos, al tiempo que reduce la capacidad de respuesta interactiva. El efecto opuesto de los segmentos de tiempo más pequeños ocurre con SCHED_RR (que reducirá el rendimiento pero aumentará la capacidad de respuesta en tiempo real).

Puede usar schedtool para establecer la política de PID específicos para todos los PID en el conjunto B como un solo comando. También se puede usar para bloquear PID específicos en núcleos específicos, lo que sería la solución óptima ya que la persistencia de la caché ya no depende del intervalo de tiempo, pero esto requiere más esfuerzo ya que debe ejecutar un comando de programación separado para cada PID.

Si cada proceso tiene su propio núcleo, entonces no hay restricciones de prioridad.

Sin embargo, si programa un proceso que demora 30 minutos en ejecutarse cada 15 minutos, comenzará a tener que priorizar ya que el proceso comenzará a superponerse.

Sin embargo, no existe una "mejor" política de programación.

Realmente dependen de lo que quieres lograr. Pero al principio, lo dejaría en SCHED_OTHER, el valor predeterminado y lo observaría por un tiempo antes de intentar cosas más especializadas.