Quels sont les effets, le cas échéant, des priorités et des politiques du planificateur pour les threads dans un cpuset non contraint?

J'ai un système Linux où nous avons utilisé des cgroups pour créer deux cpusets cpu_exclusive, A et B, et où nous avons migré tous les threads utilisateur et tous les threads du noyau non liés vers un cgroup attaché à cpuset A. Les choses qui s'exécutent dans cpuset A ont différentes politiques de programmation. et des priorités variables, et il y a beaucoup plus de threads en cours d'exécution dans cpuset A que de cœurs dans cpuset A.

Il existe également un petit nombre de processus très actifs attachés à cpuset B, où le nombre total de threads utilisateur à travers ces processus n'est jamais supérieur au nombre de cœurs exclusivement disponibles dans cpuset B. Le but est de protéger ces tâches importantes exécutées dans cpuset B d'une autre activité sur la machine et pour minimiser la latence de traitement.

Dans une telle configuration, la politique / priorité de planification des threads utilisateur s'exécutant dans cpuset B a-t-elle un effet observable? Autrement dit: la modification de la stratégie de planification des threads du cpuset B de SCHED_OTHER par défaut à SCHED_FIFO ou SCHED_RR aurait-elle des conséquences, bonnes ou mauvaises?

Il semble que la réponse devrait être «non», car le planificateur devrait être en mesure d'attribuer à chaque thread s'exécutant dans cpuset B son propre noyau dédié, il n'y aurait donc rien à prioriser ou à planifier, et donc la politique et la priorité relative du B les threads cpuset n'auraient pas d'importance. D'un autre côté, il y a les threads du noyau liés et les aspects «domaine du planificateur» à se soucier, et probablement d'autres choses que je n'ai pas prises en compte.

Les politiques et priorités de planification des threads s'exécutant dans un cpuset exclusif surapprovisionné ont-elles un sens pratique?

La tranche de temps utilisée sera importante pour les travaux gourmands en ressources processeur qui nécessitent la persistance du cache, sauf si vous verrouillez un cœur particulier sur chaque PID. Vous pouvez augmenter la tranche de temps avec la stratégie de planificateur SCHED_BATCH et améliorer les performances jusqu'à 300% dans certains cas, tout en réduisant la réactivité interactive. L'effet inverse de tranches de temps plus petites se produit avec SCHED_RR (qui réduira le débit mais augmentera la réactivité en temps réel).

Vous pouvez utiliser schedtool pour définir la stratégie de PID spécifiques pour tous les PID de l'ensemble B en tant que commande unique. Il peut également être utilisé pour verrouiller des PID spécifiques sur des cœurs spécifiques, ce qui serait la solution optimale car la persistance du cache ne dépend plus de la tranche de temps, mais cela demande plus d'efforts car vous devez exécuter une commande schedtool distincte pour chaque PID.

Si chaque processus a son propre cœur, il n'y a pas de contraintes de priorité.

Cependant, si vous planifiez un processus qui prend 30 minutes pour s'exécuter toutes les 15 minutes, vous commencerez à avoir besoin de prioriser car le processus commencera à se chevaucher.

Il n'y a cependant pas de "meilleure" politique de planification.

Ils dépendent vraiment de ce que vous voulez réaliser. Mais au début, je laisse le soin à SCHED_OTHER, la valeur par défaut et j'observe pendant un certain temps avant d'essayer des choses plus spécialisées.