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

¿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?

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.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(Casi) operación completa sin tick en 3.10"

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/ ).