Comment changer la fréquence de changement de contexte Linux?

Comment est-il possible de changer la fréquence de changement de contexte Linux (linaro, ubuntu, debian)?

Je suis d'accord pour échanger un système moins réactif contre un système plus efficace.

EDIT1: J'ai un processus principal que je veux exécuter aussi vite que possible (cycles d'horloge maximum par seconde), j'ai donc pensé à réduire la fréquence de changement de contexte (= augmenter la tranche de temps). La question est de savoir comment le faire, et y aurait-il un effet significatif. Puis-je calculer le coût du changement de contexte? Ce qui signifie, puis-je estimer si j'augmente de deux fois la tranche de temps, quel sera mon gain de performances en% pour le processus principal qui m'importe?

Si votre tâche est le seul processus demandant du temps sur une CPU spécifique, il n'y aura pas de changement de contexte entre les tâches :-). Mais le CPU peut toujours être interrompu, provoquant un changement de contexte dans le noyau et vice-versa. Et une cause possible est le temporisateur de préemption, vérifiant s'il y a une autre tâche à exécuter sur ce CPU ...

Linux peut éviter de générer des interruptions de temporisation de préemption sur le processeur lorsqu'il n'y a aucune raison de le faire. Tu vois CONFIG_NO_HZ_FULL. Pour utiliser cette fonctionnalité, elle doit être activée lors de la construction du noyau et doit être activée à l'aide d'une option de démarrage.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(Presque) fonctionnement tickless complet en 3.10"

Par défaut, aucun processeur ne sera un processeur adaptatif. Le paramètre de démarrage "nohz_full =" spécifie les processeurs adaptatifs. Par exemple, "nohz_full = 1,6-8" indique que les CPU 1, 6, 7 et 8 doivent être des CPU adaptatifs. Notez qu'il vous est interdit de marquer tous les CPU comme CPU à cocher adaptatif [...]

LWN.net dit "selon Ingo Molnar, jusqu'à 1% du temps du processeur sera économisé" pour les processeurs adaptatifs. Le document du noyau indique que cela a six coûts différents, et il y a aussi une liste de "PROBLÈMES CONNUS".

Ce gain est relativement faible, en particulier par rapport aux gains de débit potentiels de réduction de la fréquence des changements de contexte entre plusieurs tâches, comme référencé dans cette réponse: Comment changer la longueur des tranches de temps utilisées par le planificateur de CPU Linux?

Petits caractères: ces mesures sont antérieures à la prise en charge de Spectre, Meltdown, KPTI et x86 ASID :-(. Et je suppose qu'elles s'appliquent également au matériel un peu plus ancien. Demandez à un expert du noyau ou exécutez vos propres mesures sur la façon dont le coût des changements de contexte a changé sur la version et le matériel de votre noyau spécifique ... PTI était en grande partie censé être atténué par ASID, à l'exception des logiciels qui appellent très souvent le noyau, l'exemple principal étant les bases de données. Mais je n'ai pas une bonne compréhension des chiffres .

L'espoir de Molnar dans le patch RFC d'origine était qu'avec le temps, il "sera probablement activé par la plupart des distributions Linux". Je remarque que Fedora 28 fournit un noyau par défaut construit avec NO_HZ_FULLsupport. Cependant, Debian 9 ne le fait pas.

Plus récemment, Linux v4.17 supprime unnohz_full tic résiduel de temporisateur de 1 Hz des CPU . J'imagine que l'effet sur le débit est assez petit :-), mais j'ai essayé de suivre l'état des NO_HZ_FULLavantages quand il y a plusieurs processus exécutables sur un CPU -

une fois que nous atteignons 0 Hz, nous pouvons [alors] supprimer l'hypothèse de tick périodique de nr_running> = 2 également, en interrompant essentiellement les tâches occupées aussi souvent que les contraintes sched_latency nous obligent à le faire - une fois tous les 4 à 40 ms, selon nr_running .

C'est un peu déroutant car la préemption a déjà commencé à l'aide d'un tick séparé et plus précis dans v2.6.25-rc1, commit 8f4d37ec073c, "sched: tick de préemption haute résolution" . Trouvé via ce commentaire sur le même article LWN.net: https://lwn.net/Articles/549754/ ).