¿Cómo cambiar la frecuencia de cambio de contexto de Linux?

17

¿Cómo es posible cambiar la frecuencia de cambio de contexto de Linux (linaro, ubuntu, debian)?

Estoy de acuerdo en cambiar un sistema menos sensible por uno más eficiente.

EDITAR1: Tengo un proceso principal que quiero ejecutar lo más rápido posible (ciclos de reloj máximos por segundo), así que pensé en reducir la frecuencia de cambio de contexto (= aumentar el intervalo de tiempo). La pregunta es cómo hacerlo, y habría un efecto significativo. ¿Puedo calcular el costo del cambio de contexto? Es decir, si puedo aumentar el intervalo de tiempo en dos, ¿cuál será mi ganancia de rendimiento en% para el proceso principal que me interesa?

Nadav B
fuente
1
Esperaría que el efecto de esta configuración sea mínimo y relevante solo si tiene más procesos en ejecución que los núcleos de CPU. Si no hay otras tareas esperando una CPU en particular, no hay necesidad de configurar un temporizador de cambio de tareas de corta duración, ya que cualquier cosa que pueda hacer que otra tarea sea ejecutable sería una llamada al sistema o una interrupción de hardware, las cuales devolvería la CPU al núcleo.
Simon Richter
Lamento ser tonto aquí, pero ¿alguien podría explicar qué significa "frecuencia de cambio de contexto" en el contexto de esta pregunta?
user1717828
@sourcejedi vea mi EDIT1: ¿puedo estimar la mejora del rendimiento en% cuando reduzco la frecuencia de cambio de contexto?
Nadav B
@NadavB He editado mi respuesta en consecuencia. Las medidas específicas son mejores cuando se optimiza. Sin embargo, no tiene que tratarlo como recuadro negro, por ejemplo, puede usar perf para medir errores de caché si su CPU es buena. AIUI, varios tipos de pérdida de caché de CPU (incluida la falta de TLB) son los costos individuales más importantes del cambio de contexto.
sourcejedi

Respuestas:

17

Si su tarea es el único proceso que solicita tiempo en una CPU específica, no habrá cambios de contexto entre tareas :-). Pero la CPU aún puede ser interrumpida, causando un cambio de contexto en el núcleo y viceversa. Y una posible causa es el temporizador de prevención, que verifica si hay otra tarea para ejecutar en esta CPU ...

Linux puede evitar generar interrupciones de temporizador preventivo en la CPU cuando no haya razón para hacerlo. Ver CONFIG_NO_HZ_FULL. Para usar esta función, debe habilitarse cuando se compiló el núcleo y debe habilitarse mediante una opción de arranque.

Por defecto, ninguna CPU será una CPU adaptativa. El parámetro de arranque "nohz_full =" especifica las CPU de tics adaptativos. Por ejemplo, "nohz_full = 1,6-8" dice que las CPU 1, 6, 7 y 8 deben ser CPU adaptativas. Tenga en cuenta que tiene prohibido marcar todas las CPU como CPU de marca adaptativa [...]

LWN.net dice "según Ingo Molnar, se ahorrará hasta el 1% del tiempo de la CPU" para las CPU de tics adaptativos. El documento del núcleo dice que esto tiene seis costos diferentes, y también hay una lista de "PROBLEMAS CONOCIDOS".

Esta ganancia es relativamente pequeña, particularmente en comparación con las ganancias potenciales de rendimiento de reducir la frecuencia de cambios de contexto entre múltiples tareas, como se menciona en esta respuesta: ¿Cómo cambiar la duración de los segmentos de tiempo utilizados por el programador de CPU de Linux?

Letra pequeña: estas medidas son anteriores a Spectre, Meltdown, KPTI y soporte ASID x86 :-(. Y supongo que también se aplican a hardware algo más antiguo. Pregúntele a un experto en kernel o ejecute sus propias mediciones sobre el costo de los cambios de contexto cambió en su versión y hardware específicos del kernel ... Se suponía que el PID era mitigado en gran medida por ASID, excepto por el software que llama al kernel con mucha frecuencia, el ejemplo principal son las bases de datos. Pero no entiendo bien los números .

La esperanza de Molnar en el parche RFC original era que con el tiempo, "probablemente será habilitado por la mayoría de las distribuciones de Linux". Noto que Fedora 28 proporciona un núcleo predeterminado construido conNO_HZ_FULL soporte. Debian 9 no lo hace, sin embargo.


Más recientemente, Linux v4.17 elimina un tic de temporizador residual de 1 Hz de las nohz_fullCPU . Me imagino que el efecto en el rendimiento es bastante pequeño :-), pero he estado tratando de seguir el estado de los NO_HZ_FULLbeneficios cuando hay múltiples procesos ejecutables en una CPU:

una vez que alcanzamos 0 Hz, podemos [entonces] eliminar la suposición de tick periódica de nr_running> = 2 también, esencialmente interrumpiendo las tareas ocupadas con la frecuencia que las restricciones sched_latency nos obligan a hacer, una vez cada 4-40 ms, dependiendo de nr_running .

Esto es un poco confuso ya que la preferencia ya comenzó a usar una marca separada más precisa en v2.6.25-rc1, commit 8f4d37ec073c, "sched: marca de preferencia de alta resolución" . Encontrado a través de este comentario en el mismo artículo de LWN.net: https://lwn.net/Articles/549754/ ).

sourcejedi
fuente
¿Qué pasa con el kernel.sched_rr_timeslice_ms?
Nadav B
1
@NadavB si está utilizando tareas en tiempo real sched_rr, dígalo. Este es un tema especializado. Si no es así, entonces no :-).
sourcejedi